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Preface 



UM L est un langage de model isati on tres complet, qui couvre de nombreux aspects du 
developpement des logiciels, comme les exigences, I 'architecture, les structures et les 
comportements. 

Depuissa normalisation, en 1997, UML a fortement evolue, passant d'un langage peu 
formel, principalement destine a la documentation, a un langage suffisamment precis 
pour que des applications puissent etre generees a parti r des model es. Cette evolution 
vers une plus grande precision a cependant cree une cesure entre les tenants du « tout- 
modele », qui demandent toujours plus de formalisme, et les developpeurs, qui appre- 
cient UML pour sa capacite a capturer en quelques dessins les grandes lignes d'une 
application. 

Le mieux etant I'ennemi du bien, pour satisfaire les uns, il a fallu complexifier UM L au- 
dela du besoin des autres. En pratique, I' effort de formal isati on et d' abstraction requis 
par une utilisation complete du langage de model isati on peut souvent s'averer contre- 
productif lorsque I'ecriture de code est I'objectif immediat. 

Dans cet ouvrage, X avier B lane et Isabel I e M ounier presentent une approche de develop- 
pement de logiciels dans laquelle modelisation et programmation se complement harmo- 
nieusement. Leur demarche mesembletres pertinente, car el I e permet aux developpeurs 
de beneficier tout de suite d'une large part des avantages de la modelisation avec UML, 
tout en restant dans le monde de la programmation. Loin de forcer les developpeurs a 
migrer vers un etat d'esprit « tout-modele », dans lequel la production de code apparat- 
trait comme une activite subalterne, les auteurs nous montrent comment la modelisation 
et la programmation peuvent s'utiliser de maniere conjointe et complementaire. 

UML pour le developpeur est le fruit de I'experience de X avier et Isabelle, a la 
confluence des model es et du code. Leur approche pragmatique et leur demarche metho- 
dologique bien definie seronttres utiles aux developpeurs soucieux de concilier les vues 
abstraites des model es avec du code concret, faisant directement partiede I ' appl i cation a 
developper. 

Pierre-Alain Muller, maitre de conferences, Triskel I - INRIA Rennes 
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Avant-propos 



UM L (Unified M odeling Language) est aujourd'hui le langage de moderation dupli- 
cations informatiques leplus important du marche. II estsupportepar la quasi-total itedes 
outils de developpement, lesquels permettent I ' editi on de modeles UM L et offrent des 
capacites telles que la generation decode, de test etde documentation, lesuivi d' exigen- 
ces ou encore le Reverse Engineering. 

Pour autant, ce langage restetres complexeet n'est pas facile a assimiler, surtout lorsque 
nous souhaitons obtenir rapidement un gain de productivite. La raison a cela est que 
I'approche classique d'utilisation d'UM L, que nous nommons U M L pour I'architecte, 
vise surtout a uti User les modeles UM L commedes moyensde reflexion, d'echangeetde 
communication entre les membres d'une meme equipe de developpement. Cette appro- 
che suit toutes les phases du cycle de vie des applications. La generation de code n' arrive 
alors qu'a la fin et n'est rentable que si nous avons respecte scrupuleusement toutes les 
phases anterieures. La difficulty de cet exercice nous fait mieux comprendre pourquoi les 
gains de productivite ne sont que rarement obtenus. 

U ne autre approche U M L , que nous nommons U M L pour le developpeur, est deja identi- 
fiee par quelques outilleurs du marche. Davantage adaptee au developpeur qu'au travail 
en equipe, cette approche vise a obtenir des gains de productivite tres rapidement. L'idee 
principale a la base de cette approche consiste a effectuer des all ers-retours entre modeles 
UM L et code dans I'objectif d'utiliser conjointement les meilleurs avantages de chacun 
des deux mondes (modele et code). Ainsi, I'ecriture d'algorithmes, la compilation et 
I'execution sont laissees au niveau des langages de programmation, tandis que la 
decoupe en packages ou I 'application de patrons de conception s'effectue au niveau des 
modeles UM L. Des synchronisations sont effectuees entre les modeles et le code afin 
d' assurer une coherence de I 'ensemble. Cette approche tres pragmatique off re rapide- 
ment de forts gai ns de productivite. 

Ces deux approches opposees compliquent I'apprentissage d'UM L pour toute personne 
desi reuse de savoir comment utiliser ce langage dans son propre contexte. De plus, tous 
les ouvrages existants adressent principalement I'approche U M L pour I'architecte et ne 
font que peu de cas des mecanismes liant U M L au code des applications. L'etudiant, tout 
comme le developpeur de metier, ne peuvent des lors mesurer pleinement les avantages 
de ce langage pour leur contexte, qui porte essentiellement sur I e developpement du code 
des applications. 



VIII 



UML pour les developpeurs 



C'est pourquoi nous presentons dans cet ouvrage un cours exclusivement dedie a 
I'approche UML pour le developpeur. Notre objectif est de montrer la complementarite 
que peut offrir UM L a n'importe quel langage de programmation. Nous presentons dans 
chaquecas les gains de productivite que nous pouvons en obtenir. 



Une approche a contre-pied 

Le deroulement pedagogique de ce cours est volontairement a contre-pied des cours 
UML classiques. Mors que ces derniers commencent invariablement par presenter les 
fameux diagrammes de cas d' utilisation et finissent par la generation de code, nous 
proposons I' inverse, en commengant par I e code et en finissant par les diagrammes de cas 
d' utilisation. Notre objectif est de mettre au premier plan les mecanismes UML qui 
offrentdirectement des gains de productivite etd' en mesurer les impacts. Pourautant, les 
principals notions UM L auront ete introduites et commentees a la fin du cours. 



Organisation de ce cours 

Leplan dececoursestlesuivant: 

1. Un curieux besoin de modeles : ce chapitre presente les principaux avantages des 
model es UML afin de bien fairecomprendre les relations entre model eet code. Nous 
y definissons la notion de niveau d' abstraction qui permet de representer une meme 
application suivant differentes vues. 

2. Diagrammes de classes UML: ce chapitre presente le plus employe des diagrammes 
UML. Ce chapitre n'est pas un guide de reference du diagramme de classes. Nous 
presentons les concepts necessaires dans le contexte de ce cours. 

3. Reverse Engineering : ce chapitre presente les principes du Reverse Engineering, qui 
consiste a construire automatiquement un modele UM L a partir de code. Nous defi- 
nissons un ensemble de regies permettant de produire un diagramme de classes a 
partir du code d'une application. 

4. Retroconception et patrons de conception : ce chapitre presente les operations de 
restructuration d'applications effectuables sur des modeles UM L. Nous expliquons le 
role des patrons de conception et comment les appliquer sur un diagramme de clas- 
ses. 

5. Generation de code : ce chapitre presente les principes de la generation de code a 
partir de modeles UML. Nous definissons un ensemble de regies permettant de gene- 
rerdu code a partir d'un diagramme de classes. 

6. Diagrammes de sequences : ce chapitre presente les diagrammes de sequence. N ous 
expliquons en quoi ces diagrammes sont necessaires pour mieux comprendre le 
comportement d'une application. Nous insistons sur lefait qu'ils ne contiennent pas 
I 'information necessaire a la generation de code. 
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IX 



7. Diagrammes de sequences et tests : ce chapitre presente I ' utilisation des diagrammes 
de sequence pour la generation de tests. Nous expliquons les principes du test 
d'application et sa mise en oeuvre par I ' i ntermedi ai re de diagrammes de sequence de 
test. 

8. U M L et les plates-formes d'execution : ce chapitre presente les relations entre UM L 
et les plates-formes d'execution afin de bien faire comprendre la capacite d'abstrac- 
tion des model es UM L. Nous insistons sur I e fait qu'il est important, pour une meme 
application, d' avoir des model es independants de la plate-forme d'execution et 
d'autres plus etroitement lies a cette derniere. 

9. Diagrammes de cas d' utilisation : ce chapitre presente les diagrammes decasd' utili- 
sation. I Is sont utilises pour representer les fonctionnalites d'une application quel que 
soit le niveau d'abstraction considers 

10. Developpement avec UML : ce chapitre presente une methode de developpement 
avec UML permettant d'obtenir I' ensemble des diagrammes necessaires a la repre- 
sentation d'une application Nous partons cette fois de la description de I'application 
et nous expliquons I' ensemble des etapes a suivre pour obtenir le code de I'applica- 
tion tout en ayant construit I 'ensemble des diagrammes necessaires pour faire le lien 
entre tous les niveaux d'abstraction. 

Pour rendre plus concrete les relations entre code et model e, nous avons choisi de baser 
ce cours sur le langage J ava. Tous les mecanismes de generation de code ou de Reverse 
Engineering que nous presentons s'appuient done sur Java. Les principes que nous 
presentons dans ce cours sont cependant transposables vers d'autres langages de 
programmation. 

Chaque cours est suivi d'un ensemble d'exercices complementaires du cours. Nous 
soulignons que la lecture de la partie cours uniquement ne permet pas d'acceder a 
I 'ensemble des informations presentees dans ce livre. 

A qui s'adresse ce cours ? 

Cet ouvrages'adresse principalementaux etudiants etaux developpeurs de metier ayant 
des connaissances en programmation par objetsetdesireux dedecouvrir les benefices du 
langage UML pour le developpement d'applications. 1 1 ne s'agit pas d'un guide de refe- 
rence sur U M L . 

Chaque notion importante dans le contexte du developpement avec UML est introduite 
par un exemple, et chaque chapitre se clot par une serie d'exercices (91 au total) avec 
corriges, qui permettront au lecteur de tester ses connaissances. 

L'ouvrage s'adresse aussi aux enseignants desireux de transmettre les principes de base 
des langages de model isati on selon uneapproche pragmatique, en liaison avec les techni- 
ques classiques de developpement d'applications. 
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Un curieux besoin de modeles 



Objectifs 

■ Sensibiliser le lecteur a la complexite intrinseque de la construction d'applications 
informatiques 

■ Motiver le besoin de modeliser pour gerer cette complexite et non la simplifier 

■ Comprendre la place du modele par rapport au code 

Construction d'applications 

En simpl ifiant a I 'extreme, nous pourrions dire que la construction d'une application 
informatique se resume a realiser du code pour repondre au besoin d'un utilisateur, aussi 
appele client. 

La figure 1.1 illustre cette simplification en prenant I'exemple de Word, qui a ete congu 
pour permettre, entre autres, a ses utilisateurs d'ecrire des livres ou des lettres. 

Figure 1.1 I 1 



Simplification 
extreme de la 
realisation d'une 
application 
informatique 




Avoir un logiciel 
pour ecrire un livre 
ou une lettre 



Word 
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Cette simplification peut etre considered comme grossiere. E Me a cependant le merite de 
bien rappeler la finalite de I'activite de construction d'applications informatiques, qui est 
de real i ser I e code. 

Pour autant, la realisation du code n'est pas la seule activite a effectuer lorsque nous 
souhaitons construire une application. 

Parmi les autres activites non moins indispensables a effectuer, citons notamment les 
suivantes : 

• S'assurer d'avoir bien compris le besoin de I ' uti I i sateur afin de real iser un code qui le 
satisfasse. II nefautpas se mettre a la place de I 'uti I i sateur ni essayer d'imaginer son 
besoin. L'issue fatal e serai t alors de real iser un code ne satisfaisant pas I 'uti I i sateur. 

• S'assurer d'avoir realise un code facilement modifiable, permettant de prendre en 
compte des evolutions futures. 

• Definir I 'architecture de I ' appl i cation (definition de ses differents composants, inde- 
pendamment du langage de programmation) afin de bien comprendre les relations 
entre les composants de I ' appl i cation. 

• Realiser une batterie de tests afin de mesurer, d'une certaine maniere, la qualite du 
code. 

• Effectuer un suivi des besoins de I 'uti I i sateur afin d'integrer des ameliorations. 

• Effectuer des corrections de bogues. La presence de bogues etant inevitable, il faut la 
gerer plutot que la subir. 

• E cri re la documentation uti I i sateur. 

• Ecrire la documentation d' installation de I ' appl i cati on. 

• Ecrire la documentation de I ' appl i cati on afin qu'une autre equipe de developpeurs 
puisse reprendre le developpement. 

• Effectuer des tests de montee en charge afin de mesurer les capacites de resistance et la 
performance de I ' appl i cati on. 

• Effectuer une separation des taches de developpement afin de raccourcir les delais de 
livraison de I ' appl i cati on. 

Ces activites visent a mieux structurer I'ensemble des taches a effectuer lors de la cons- 
truction d'une application. Notons, de plus, que certaines activites dependent d'autres et 
qu'il faut parfois imperativement effectuer une activite avant d' en demarrer une autre. 

La figure 1.2 presente une vision de I'ensemble de ces activites et de leur entrelacement 
(chaquefleche precise une dependance dans la realisation des activites). Cette figure fait 
bien ressortir la complexity intrinseque de la construction d'une application. Nous 
voyonsclairement qu'il y a beaucoup d'activites a realiser et quel' ordrede realisation de 
ces activites n'est pas trivial. 



Un curieux besoin de modeles 



Chapitre 1 




Figure 1.2 

Vision d'une partie des activites a realiser pour construire une application 



Pour faire face a cettecomplexitede construction des applications informatiques, I'inge- 
nierie logicielle propose depuis plusieurs annees des methodes et des techniques permet- 
tant de repondre aux questions suivantes : 

• Quand realiser une activite? 

• Qui doit realiser une activite? 

• Quoi faire dans une activite? 

• Comment realiser une activite? 
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Ces questions synthetisent grosso modo le probleme de la construction d'applications 
informatiques. Les deux premieres vi sent a identifier et organiser les differentes activites 
necessaires a la construction d'une application informatique. Les deux dernieres visent a 
bien definir les travaux devantetre realises dans chacune des activites. 

L'etendue de la tache et 1'evolution constante des technologies nous font mieux 
comprendre pourquoi I'ingenierie logicielle est un domaine ouvert, dans lequel nombre 
de probl ernes restent encore a resoudre. 

Dans le cadre de ce cours, nous nous focalisons uniquement sur les activites relatives au 
code (generation, analyse, documentation, tests, etc.). De plus, nous ne traitons quasi- 
ment pas les deux questions relatives a I'organisation des activites (quand et qui). Notre 
objectif est de montrer en quoi les differentes techniques de modelisation UML (quoi et 
comment) permettent d'obtenir rapi dement un gain de productivity 



Le code 

Nous avons introduit a la section precedente un ensemble non exhaustif d' activites qu'il 
est necessaire de real iser pour construire une application informatique. Dans cet ensem- 
ble, la realisation du code n'apparait que comme une activite parmi d'autres. 

Cependant, comme nous I 'avons indique, la realisation du code reste la final ite. Toutes 
les autres activites visent soit a faciliter cette realisation, soit a I'optimiser, soit a permet- 
tre son evolution. 

Le code occupe done une place particuliere dans la construction d'une application infor- 
matique, maislaquelleexactement? 

Une premiere certitude est que, pour executer une application, il fautlacoder. Lecodeest 
done absolument necessaire a I 'execution des applications. Peut-on dire pour autant que 
le code soit I ' appl i cati on ? En d'autres termes, peut-on considerer que lecode, a lui seul, 
represente I ' i ntegral ite de I ' appl i cati on ? 

Les questions suivantes permettent de mieux cerner la place du code dans une appl i cati on 
informatique : 

1. Question. Comment le code peut-il etre utilise pour faciliter la maintenance des 
applications informatiques ? 

Reponse. Nous pourrions penser a commenter le code afin de faciliter la mainte- 
nance, mais il faudrait alors definir le niveau de detail adequat. La charte Linux 
propose, parexemple, de nepas« surdocumenter » lecode, car celui-ci devientvite 
illisible. Dans le projet Linux, les commentaires sont utilises pour specifier des 
travaux a faire ou des points delicats mais ne sont pas destines a la maintenance. 
Nous pouvons done considerer que le code ne peut pas reellement etre utilise pour 
faciliter la maintenance. 

2. Question. Comment pouvons-nous retrouver les foncti onnal ites d'une application en 
lisant lecode? 
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Reponse. C'est un travail difficile, qui ne peut etre automatise. II est necessaire de 
constituer une documentation differente du code pour expliquer a d'autres personnes 
les fonctionnalites de I ' appl i cati on. 

3. Question. Comment pouvons-nous decrire la facon de mettre en production une 
application ? 

Reponse. Lecodeneserta rien pour eel a. II est necessairedefournir une documenta- 
tion d'installation. 

4. Question. Comment pouvons-nous decrire la facon d'utiliser une application ? 

Reponse. Lecode nesert a rien la non plus. II est necessairedefournir une documen- 
tation d'utilisation. 

Ces quelques questions-reponses permettent de comprendre, d'une part, que le code 
occupe une place indispensable dans la construction d'une application et, d'autre part, 
qu'il nepermetpas, a lui seul, de representer toute I'application. II est necessai red' avoir 
d'autres ressources (guide, documentation, etc.) pour supporter certaines activites de 
developpement (maintenance, installation, etc.). 

Pour illustrer cette difference entre code et application informatique, nous considererons 
dans la suite du cours que la construction d'une application consiste a realiser une solu- 
tion au problemed'un utilisateur (voir figure 1.3). Lecode est la materialisation de cette 
solution. En d'autres termes, lecode seul ne suffit pas. 



Figure 1.3 

Deuxieme 
simplification 
de la realisation 
d'une application 




Avoir un logiciel pour 
ecrire un livre ou une 
lettre 



Word 



Code source de Word 



Nous considerons que, quel que soit le langage de programmation, le code a pour unique 
objectif d'etre compile et execute. Toutes les autres informations utiles au developpe- 
ment d'une application n'ont pas reellement leur place dans lecode. 
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Documentation 

Ce constat de difference entre code et application informatique n'est pas nouveau. On 
s'accorde d'ailleurs aujourd'hui sur un ensemble de documents necessaires a real iser 
pour completer lecode. 

Le tableau 1.1 recense un sous-ensemble des documents a realiser lors de la construction 
d'une application. Ces documents sont echanges entre les clients de I ' appl i cati on et les 
differents membres de I'equipe de developpement. Nous identifions parmi ces derniers 
I'architecte, dont le role est de concevoir les composants principaux de I'application, le 
devel oppeur, dont I e rol e est de devel opper I es composants de I ' appl i cati on, et I ' admi ni stra- 
teur, dont le role est d' installer I'application afin qu'elle puisse etre uti I i see par I ' uti I i sateur. 

I nsistons a nouveau sur I e fait que ces documents ne peuvent etre directement integres au 
code, que ce soit sous forme de commentaire ou autre. 



Tableau 1.1 Liste non exhaustive des documents necessaires a la realisation d'une application 



Document 


Fonction 


Documentation utilisateur 


Precise la fagon dont on peut utiliser I'application. Un tel document peut aussi 
contenir une section decrivant la fagon d'installer I'application. Ce document est 
redige par I'equipe de developpement et est destine aux utilisateurs de I'applica- 
tion. 


Documentation des services 
offerts par I'application 


Presente une vision macroscopique de I'application et liste les fonctionnalit.es 
realisees par I'application. Ce document est redige par I'equipe de developpe- 
ment et est destine aux utilisateurs de I'application. 


Documentation d 'architecture 
de I'application 


Precise la fagon dont I'application est structures en terme de gros composants. 
Ce document est redige par les architectes et est destine a tous les membres de 
I'equipe de developpement. 


Documentation des logiciels 
necessaires a I'utilisation de 
I'application 


Dresse la liste des logiciels necessaires a I'installation et a I'execution de I'appli- 
cation. Ce document est redige par I'equipe de developpement et est destine 
aux administrateurs, afin qu'ils puissent mettre I'application en production. 


Documentation des tests 
effectues 


Liste I'ensemble des tests qui ont ete effectues sur I'application. On peut de la 
sorte tester a nouveau I'application apres I'avoir modifiee et verifier ainsi qu'elle 
ne genere pas d'erreurs sur certains scenarios d'utilisation (scenarios couverts 
par les tests). Ce document est redige par I'equipe de developpement et est des- 
tine aux developpeurs futurs. 


Documentation de la concep- 
tion de I'application 


Precise la conception de I'application (en terme de classes, par exemple). Ce 
document est redige par I'equipe de developpement et est destine aux deve- 
loppeurs. 


Specification des besoins 


Precise les besoins exprimes par le futur utilisateur de I'application, aussi appele 
client. Ce document est redige par le client et est destine a I'equipe de develop- 
pement. 



Cette liste donne la mesure de I'etendue du probleme de la documentation des applica- 
tions. II faut non seulement rediger enormement de documentations, mais surtout faire 
attention a ce que ces documentations soient comprehensibles (afin que redacteurs et 
lecteurs se comprennent) et qu'elles soient coherentes entre el les. 
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Chapitre 1 




Ce probleme peut etre resume de la fagon suivante : 

• Comment rediger les documentations afin qu'elles soient intelligibles de maniere non 
ambigue (en anglais ? en frangais ? faut-il definir un dictionnairecommun ?) ? 

• Comment s' assurer que les documentations ne contiennent pas d' incoherences ? 

C'est pour repondre a ces questions que les modeles sont de plus en plus utilises lors de 
la construction des applications. 

Les modeles 

Avant de preciser en quoi les modeles sont interessants pour la construction d' applica- 
tions informatiques, il est interessant de preciser la definition du terme modele. 

Ledictionnairedela I angue franchise en ligneTLFI (Tresor de la languefrangaise infor- 
matise) donne les definitions suivantes du mot « modele » (http://atiif.atiif.fr/tif.htm) .- 

• A rts et metiers : representation a petite echelle d'un objet destine a etre reproduit dans 
des dimensions normal es. 

• Epistemologie : systeme physique, mathematique ou logique representant les struc- 
tures essentielles d'une real ite et capable a son niveau d'en expliquer ou d'en repro- 
duce dynamiquement lefonctionnement. 

• Cybernetique : systeme artificiel dont certaines proprietes presentent des analogies 
avec des proprietes, observees ou inferees, d'un systeme etudie et dont le comporte- 
ment est appele, soit a reveler des comportements de I'original susceptibles de faire 
I 'objet de nouvelles investigations, soit a tester dans quelle mesure les proprietes attri- 
buees a I'original peuvent rendre compte de son comportement manifeste. 

Dans un contexte informatique, nous proposons la definition suivante, qui synthetise les 
trois definitions enoncees precedemment : 



Modele (informatique et construction d'applications) : les modeles d'applications informatiques sont des 
representations, a differents niveaux d'abstraction et selon plusieurs vues, de I'information necessaire a la 
production et a revolution des applications. 



Un modele contient done plusieurs informations sur une application informatique. Ces 
informations onttoutes vocation a faci I iter d'une maniere ou d'une autre la production du 
code de I ' appl i cati on. Un modele peut, entre autres choses, preciser les differentes 
donnees manipulees par I ' appl i cati on (vue des donnees), preciser les differentes fonc- 
tionnalites directement offertes aux utilisateurs de I 'application (vue des utilisateurs) et 
preciser les technologies, tel les que Java, uti I i sees pour real iser I 'application (vue techni- 
que). 

En d'autres termes, un modele est compose de plusieurs vues sur une application. 
Chacune de ces vues contient certaines informations sur I 'application. Ces vues peuvent 
cibler differents niveaux d'abstraction, et el I es doivent etre coherentes. 
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La figure 1.4 schematise un modeled' application compose detrois vues. 




Les modeles integrent done differentes vues, a differents niveaux d'abstraction d'une 
meme application informatique. L'ensemble des vues doit etre coherent ; deux vues ne 
doiventdonc pas specifier d'information incoherente. 

Les modeles permettent ainsi d'harmoniser l'ensemble des documentations des applica- 
tions informatiques en un unique ensemble coherent. 

Pour pouvoir utiliser des modeles, il faut definir un langage de model isati on partage par 
tous. Nous traitons dans le cadre de ce cours du langage UML, qui est le langage de 
modelisation d'applications informatiques leplus largement partage aujourd'hui. 



Modeles et code 

Nous venons de voir que les modeles contenaient, selon differentes vues et a differents 
niveaux d'abstraction, I'information necessairea la production eta I 'evolution des appli- 
cations informatiques. 

Rappelons que le code est different du model e. II est, comme nous I'avons deja indique, 
la materialisation de la solution. 



Un curieux besoin de modeles 

Chapitre 1 



Cependant, il est important d'aj outer les precisions suivantes : 

• Le code n'est pas plus detaille que les modeles. En effet, le model e devant contenir 
toute I'information permettant la production du code, un modele doit etre au moins 
aussi detaille que I e code. 

• Faire un modele n'est pas plus facile qu'ecrire du code. En effet, le modele contient 
beaucoup plus d' information que I e code. De plus, ces informations fortementdiversi - 
fiees se doivent d'etre coherentes. L'elaboration d'un modele complet est done un 
exercice encore plus difficile que la redaction de code. 

• Ne pas confondre niveau d'abstraction et niveau de precision. Nous entendons par 
abstraction lefaitde pouvoir masquer dans une vuecertaines informations inutiles par 
rapport a I'objectif bien defini de cette vue. Par exemple, il n'est pas interessant de 
montrer les details techniques Java dans la vue des donnees. Pour autant, toutes les 
informations de chaque vue doivent etre precises. 

• Les modeles doivent etre productifs plutot que declaratifs. L'objectif des modeles est 
de contenir I'information necessai re a la production eta I 'evolution du code. Les infor- 
mations contenues dans les modeles doivent done etre synchronisers avec le code. 
C est la raison pour laquelle nous considerons les modeles comme des elements de 
production plutot que comme des elements de documentation. 

Figure 1.5 ^ VUES 

Concept de modele 
U M L d'une 
application 
informatique, avec 
lesvues, les niveaux 
d'abstraction, 
les relations de 
coherence et la 
relation avec le code 



Structure 



Comportement 



Fonctionna lite 























COHERENCE 
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Notre cours se concentre sur le langage de modelisation UML. Plus precisement, parmi 
les vues proposees par ce langage, nous nous attacherons a presenter les vues 
« structurelle », « comportementale » et « fonctionnelle ». 

Nous presenterons chacunede ces vues selon trois niveaux d'abstraction et expliquerons 
les relations de coherence qui existent entre chacune de ces vues a chaque niveau 
d'abstraction. Nous preciserons de plus la relation de synchronisation qui existe entre le 
modele UM L etlecode. 

La figure 1.5 synthetise le concept de modele tel que nous le presentons dans ce cours, 
avec ses differentes vues, ses differents niveaux d'abstraction, ses relations de coherence 
etsa relation avec I e code. 

Nous considerons qu'un modele est compose de neuf parties, une partie a chaque inter- 
section d'unevueetd'un niveau d'abstraction. 

Nous nous attacherons tout au long de ce cours a preciser comment utiliser UML selon 
cette representation. 



Synthese 

Dans ce premier chapitre, nous avons passe en revue toutes les activit.es necessaires a 
la construction d'applications informatiques et ainsi souligne la complexity 
intrinsequede cette tache. Rappelons que ces activites permettent uniquementdegerer 
cette complexity etnon dela simplifier. 

Nous avons ensuite presente la place du code dans une application informatique, en 
insistant sur le fait que le code n'etait que la materialisation d'une application 
informatique. Nous avons detaille une partie des documents necessaires a la 
realisation des applications. La definition de I 'ensemble de ces documents permet 
essentiellementde repondreaux questions du comment etquoi elaborer. 

Nous avons egalement introduit le concept de modele. Les modeles d'applications 
informatiques sont des representations, a differents niveaux d'abstraction, de 
I'information necessairea la production eta I ' evolution des applications. Un modele 
contient done un ensemble d'informations coherentes sur une application 
informatique. 

Pour finir, nous avons precise le concept de modele tel qu'il sera etudie dans le cadre 
de ce cours, e'est-a-dire selon les vues « structurelle », « comportementale » et 
« fonctionnelle », sur trois niveaux d'abstraction. Nous presenterons de plus les 
relations de coherence entre ces elements de modeles ainsi que la relation de 
synchronisation avec le code. 



Un curieux besoin de modeles 



Chapitre 1 



Travaux diriges 

TD1. Un curieux besuin de modeles 



A partir du code donne en annexe de I'ouvrage, repondez aux questions suivantes. 

Question 1. En une phrase, quels sont les roles de chacune des classes ? 

Question 2. Peut-on dire qu'il existe des classes representant des donnees et des 
classes representant des interfaces graphiques ? Si oui, pourquoi et 
quelles sont ces classes ? 

Question 3 Est-il possible que le numero de telephone d'une personne soit 
+33 1 44 27 00 00 ? 

Question 4 Est-il possible que I'adresse e-mail d'une personne soit 
« je_ne_veux_pas_donner_mon_email » ? 

Question 5 Quelles sont les fonctionnalites proposees par les menus graphiques de 
cette application ? 

Question 6 Quelles sont les fonctionnalites reellement realisees par cette 
application ? 

Question 7 Est-il possible de sauvegarder un repertoire dans un fichier ? 

Question 8 Si vous aviez a rediger un document decrivant tout ce que vous savez sur 
cette application afin qu'il puisse etre lu par un developpeur qui veut reuti- 
liser cette application et un chef de projet qui souhaite savoir s'il peut inte- 
grer cette application, quelles devraient etre les caracteristiques de votre 
document ? 

Question 9 Redigez un document presentant /'application MyAssistant. 

Question 10 Redigez un document decrivant les fonctionnalites de /'application 
MyAssistant. 

Question 11 Redigez un document decrivant I' architecture generate de /'application 

MyAssistant. 



Ce TD aura atteint son objectif pedagogique si et seulement si : 

• Vous avez conscience que le code seul ne suffit pas pour decrire une application. 

• Vous avez conscience que la construction de documentations est un travail labo- 
rieux et delicat. 

• Vous commencez a comprendre I'interet de la modelisation. 
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Objectifs 

■ Presenter les concepts UML relatifs a la vue structured (diagramme de classes) 

■ Presenter la notation graphique du diagramme de classes UML 

■ Expliquer la semantique des classes UML (compatible avec la semantique des 
langages de programmation orientes objet) 



Vue structurelle du modele UML 

La vue structurelle du modele U M L est la vue la plus uti I i see pour specifier une applica- 
tion. L'objectif de cette vue est de model iser la structure des differentes classes d'une 
application orientee objet ainsi queleurs relations. 

Paradigme oriente objet 

Congu a I'origine, au cours des annees 1990, pourfaciliter la construction d'applications 
orientees objet (00), le langage UM L a ensuitefortement evolue jusqu'a sa version 2.1 
actuelle. Neanmoins, UML reste toujours tres 00. Les concepts qu'il propose pour 
model iser la vue structurelle sont done les concepts de classe et d' objet. 

UML definit cependant sa propre semantique 00 , laquelle ressemble a la semantique des 
langages de programmation objetjava ou C++. II est done important de considerer UM L 
comme un langage a part entiere, et non comme une couche graphique permettant de 
dessiner des applications Java ou C++. 



UML pour les developperus 



L'objectif de I' ensemble de ce cours etant de presenter UML pour le developpeur, un 
minimum de connaissances du paradigme oriente objet est requis. Les concepts elemen- 
taires suivants du paradigme objet seront done supposes connus : 

• objet 

• classe 

• instance 

• heritage 

• polymorphisme 

• encapsulation 

Concepts elementaires 

Les concepts elementaires que nous presentons dans cette section sont les plus employes 
pour la realisation de la vuestructurelled'un modele UM L. 

Classe 

Semantique 

En UM L, une classe definit la structure commune d'un ensemble d'objets et permet la 
construction d'objets instances de cette classe. Une classe est identifiee parson nom. 



Une classe se represente a I 'aide d'un rectangle, qui contient le nom de la classe. La 
figure 2.1 il lustre la classe nominee Personne. 



Interface 

Semantique 

En UM L, une interface definit un contrat que doivent respecter les classes qui real isent 
I'interface. Une interface est identifiee par son nom. Les objets instances des classes qui 
real isent des interfaces sont aussi des instances des interfaces. Une classe peut real iser 
plusieurs interfaces, et une interface peut etre real i see par plusieurs classes. 



U ne i nterface se represente de deux fagons : soita I 'aide d'un rectangle contenant I e nom 
de I'interface, au-dessus duquel se trouve la chame de caracteres «interface», soit a 
I 'aide d'un cercle, au-dessous duquel se trouve le nom de I'interface (voir figure 2.2). 




Graphique 



Figure 2.1 

Representation 
graphique 
d'une classe 



Personne 



Graphique 



Diagrammes de classes 



Chapitre 2 



Figure 2.2 

Representations 
graphiques 
d'une interface 



« interface* 
IPersonne 




IPersonne 



La relation de realisation entre une classe et une interface est representee par unefleche 
pointilleea la teteen forme de triangle blanc. 

La figure 2.3 represente la classe Personne qui real i se I ' i nterf ace IPersonne. 



Figure 2.3 

Representation 
gra phi que d'une 
relation de 
realisation 



«interface» 
IPersonne 



Personne 



Propriete (anciennement appelee attribut) d'une classe ou d'une interface 

Semantique 

Les classes et les interfaces peuvent posseder plusieurs proprietes. Une propriete a un 
nom et un type. Le type peut etre soit une classe UM L, soit un type de base (integer, 
string, boolean, char, real). Un objet i nstance de la classeou de I' interface doit porter les 
valeurs des proprietes de sa classe. 

Graphique 

Les proprietes d'une classeou d'uneinterfacese represented dans le rectangle represen- 
tant la classeou I' interface. Chaque propriete est representee par son nom et son type. 

La figure 2.4 presente la classe Personne, avec sa propriete nom detype string. 



Figure 2.4 

Representation 
graphique 
d'une propriete 
d'une classe 



Personne 

nom : string 



Operation d'une classe ou d'une interface 

Semantique 

Les classes et les interfaces peuvent posseder plusieurs operations. Une operation a un 
nom et des parametres et peut lever des exceptions. Les parametres sont types et ont un 

Sens (in, out, inout, return). 
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U n objet instance de la classe ou de I ' i nterf ace est responsable de la realisation des opera- 
tions definies dans la classe ou dans I' interface. 

Si le sens d'un parametre de I 'operation est in, I 'objet appelant I 'operation doitfournir la 
valeurdu parametre. Si le sens d'un parametre de I 'operation est out, I 'objet responsable 
de I' operation doit fournir la valeur du parametre. Si le sens d'un parametre de I 'opera- 
tion est inout, I 'objet appelant I 'operation doitfournir la valeur du parametre, mais eel I e- 
ci peut etre modifiee par I'objet responsable de I'operation. 

Un seul parametre peut avoir return commesens, etil n'estalors pas necessairede preci- 
ser le nom de ce parametre. Si une operation possede un parametre dont le sens est 
return, cela signifie que I 'objet responsable de I'operation rend cette valeur comme resul- 
tat del 'operation. L'apportde la direction return par rapport a la direction out est de faci- 
liter la combinaison defonction. 

Pour finir, les exceptions d' une operation sonttypees. 

II est important de souligner que les operations U M L ne definissent pas le comportement 
qui sera realise lors de I'invocation de I'operation. Nous verrons dans la suite du cours 
comment ce comportement est integredans le modele. 

Graphique 

Les operations d' une classe ou d' une interface se represented dans I e rectangle represen- 
tant la classe ou I 'interface. Chaque operation est representee par son nom et ses parame- 
tres. II estaussi possible de masquer les parametres de I'operation. 

La figure 2.5 presente la classe Personne avec son operation getNom. 

Figure 2.5 

Representation 
graphique 
d'une operation 
d'une classe 

Heritage entre classes 

Semantique 

En UML, une classe peut heriter d'autres classes. L' heritage entre classes UML doit etre 
considere comme une inclusion entre les ensembles des objets instances des classes. Les 
objets instances des sous-classes sont des objets instances des superclasses. En d'autres 
termes, si une classe A herite d'une classe B, I'ensemble des objets instances deA est 
inclus dans I'ensemble des objets instances de B. 

Ce faisant, tout objet instance deA doit posseder les valeurs des propriet.es definies dans 
A etdansB et doit etre responsable des operations definies dans A etdansB. 



Personne 

nom : string 
getNom() 



N ous verrons dans la suite de ce cours que I a relati on d' heritage entre deux classes appar- 
tenant a des packages differents depend de certaines regies. 
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Chapitre 2 
Graphique 

La relation d' heritage entre deux classes est representee par une fleche a la tete en forme 
de triangle blanc. 

La figure 2.6 represente la classe Personne, qui heritede la classe Etrevivant. 



Figure 2.6 

Representation 
graphique de la 
relation d'heritage 
entre classes 



EtreVivant 



Personne 



Package 

Semantique 

Un package permet de regrouper des classes, des interfaces et des packages. Classes, 
interfaces et packages ne peuvent avoir qu'un seul package dans lequel ils sont regrou- 
pes. La possibility d'etablir un lien entre des classes et des interfaces depend du lien qui 
existe entre les packages qui les contiennent. 

Nous detail Ions ces concepts avarices a la section suivante. 
Graphique 

Les packages se represented a I'aided'un rectangle possedant un onglet dans lequel est 
inscrit le nom du package. Les elements contenus se represented dans le rectangle. La 
tailledu rectangle s'adapte a la taillede son contenu. 

La figure 2.7 represente I e package nomme personnel, qui contient la classe Personne. 



Figure 2.7 

Representation 
graphique 
d'un package 



personnel 



«interface» 
IPersonne 



Personne 
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Import de package 

Semantique 

A fin que les classes d'un package puissent heriter des classes d'un autre package ou y 
etreassociees (voir section suivante), il fautpreciser une relation d'importentre cesdeux 
packages. La relation d'import est monodirectionnelle, c'est-a-dire qu'elle comporte un 
package source et un package cible. Les classes du package source peuvent avoir acces 
aux classes du package cible. 

Nous revenons sur cette semantique au chapitre 4 de ce cours, mais nous pouvons deja 
mentionner que nous considerons comme interdits les cycles de relations d'import entre 
plusieurs packages. 

Graphique 

La relation d'import entre deux packages s'exprimea I'aide d'une fleche en pointille. La 
chaine de caracteres access el ement i nscrite au-dessus de cette fleche peut etre optionnel- 
lement positionnee. 

La figure 2.8 presente la relation d'import entre deux packages PI et P2 contenant 
respectivement les classes A et B. Nous considerons ici quelaclasseA a besoin d'acce- 
der a la classe B. 



Figure 2.8 

Representation 
graphique de la 
relation d'import 
entre deux packages 



pl 






P2 






> 




A 


B 







Note 

Semantique 

Une note UML estun paragraphedetextequi peut etre attache a n'importe quel element 
du modele UML (package, classe, propriete, operation, association). Le texte contenu 
dans la note permet de commenter I 'el ement cible par la note. 

Graphique 

Les notes se represented a I'aide d'un rectangle contenant le texte et dont un des coins est 
corne. U ne ligne discontinue permet de relier la note a I 'el ement du modele qu'elle cible. 

La figure 2.9 represente une note attacheea I 'operation nominee getNomo. 



Figure 2.9 

Representation 
graphique 
d'une note associee 
a une operation 



Person ne 



nom : string 



getNomO 



Cette operation permet 

d'obtenir le nom de 

la personne (propriete nom) 
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Associations entre classes 

LelangageUM L defi ni 1 1 e concept d' associ ati on entre deux classes. Ceconcepttres inte- 
ressant, qui ne fait pas partie des concepts elementaires du paradigme objet, permet de 
preciser les relations qui peuvent exister entre plusieurs objets. 

En UM L, une association se fait entre deux classes. Ellea un nom etdeux extremites, qui 
permettent de la connecter a chacune des classes associees. Lorsqu'une association est 
definie entre deux classes, cela signifie que les objets instances de ces deux classes 
peuvent etre rel i es entre eux. 

La figure 2.10 presente I'association nominee habite, qui associe les classes Personne et 
Adresse. Cette association signifie que les objets instances de la classe Personne et les 
objets instances de la classe Adresse peuvent etre relies. En d'autres termes, cela signifie 
que des personnes habitent a des adresses. 



Figure 2.10 

Representation 
graphique 
d'une association 
nommee 



Personne 


habite 




nom : string 
tel[1..4]:string 






Adresse 




prenom[l..*]:string 






getNomO 







Chaque extremite de I'association a un nom de role, qui permet d' identifier chacune des 
classes liees dans le contexte de I'association. 

La figure 2.11 represente la meme association en precisant le nom des roles de chaque 
classe liee. Dans le contexte de cette association, la classe Personne represente I 'habitant 
alors que la classe Adresse represente la residence. En d'autres termes, cette association 
signifie que les personnes habitent a des adresses et qu'ils sont les habitants de ces resi- 
dences. 



Figure 2.11 

Representation 
graphique 
d'une association et 
de ses roles 



Personne 


habitant 


habite 


residence 




nom : string 
tel[1..4]:string 










Adresse 








prenom[l..*]:string 


* 




1 




getNomf) 











En UM L, il est possible de specifier a chaque extremite les nombres minimal et maximal 
d' objets devantetre relies. 

La figure 2.12 represente I a meme association en precisant les nombres minimal et maxi- 
mal d' objets devant etre relies. La lecture de ce diagramme est la suivante : 

• residence i: pour 1 habitant, il y a au minimum 1 residence et au maximum 
1 residence. 
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• habitant * : pour 1 residence, il y a au minimum 0 habitant etau maximum une infinite 
d' habitants. 

En UM L, il est possible derendrechacunedes extremites navigable ou non. Si une extre- 
mite est navigable, cela signifie que I'objet peut naviguer vers I'autre objet auquel il est 
relie et ainsi obtenir les valeurs de ses proprietes ou invoquer les operations dont il est 
responsable. 

A la figure 2.12, les habitants peuvent naviguer vers leurs residences (et pas I'inverse), ce 
qui permetd' obtenir, parexemple, lenumero derue. 



Figure 2.12 

Representation 
graphique 
d'une association 
navigable 



Personne 


habitant 


ha bite 


residence 




nom : string 
tel[1..4]:string 










Adresse 






> 


prenom[l..*]:string 


* 




1 




getNomf) 











Pourfinir, il est possible en UM L depreciserdessemantiquesdecontenancesur les asso- 
ciations. Par exemple, il est possible de preciser sur une extremite qu'une classe associee 
joue un role de conteneur, I'autre classe jouant le role de contenu. 

UML propose deux semantiques de contenance : une semantique de contenance faible, 
dited'agregation, qui permetde preciser que les elements contenus peuvent etre partages 
entre plusieurs conteneurs, et une semantique de contenance forte, dite composition, qui 
permet de preciser que les elements contenus ne peuvent etre partages entre plusieurs 
conteneurs. 

Du point devue graphique, la relation de contenance se represented I'aided'un losange 
sur I' extremite. Le losange est blanc pour I'agregation et noir pour la composition. 

La figure 2.13 precise que la classe Personne joue un role de conteneur pour la classe 
CompteBancaire dans le cadre de I'association moyens de paiement, ce qui signifie qu'un 
compte bancai re ne peut etre le « moyen de paiement » que d' une seule personne. 



Personne 



nom : string 
tel[1..4]:string 
prenom[l..*]:string 
getNomf) 



ti tula ire 



moyens de paiement compteCourant 



^> CompteBancaire 



Figure 2.13 

Representation graphique d'une association de composition 
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Concepts avarices 

L es concepts el ementai resquenousvenonsde presenter sont I argement utilises pour modeli ser 
la vue comportementale d'une application. Les concepts avances que nous presentons le sont 
moins mais permettent cependant defaciliter la realisation des operations de Reverse Enginee- 
ring et de generation de code que nous presenterons dans les chapitres suivants de ce cours. 

Classe abstraite 

Semantique 

Une classe UM L peut etre abstraite. Dans ce cas, el I e ne peut pas directement instancier 
un objet. 

Dans une classe abstraite, il est possible de preciser que certaines proprietes et certaines 
operations sont abstraites. Ce sont precisement les valeurs de ces proprietes et les respon- 
sabi litis de ces operations que les objets ne peuvent pas supporter directement. C est la 
raison pour laquelle aucun objet ne peut etre directement instance d'une classe abstraite. 

Pour que des objets soient instances d'une classe abstraite, il faut obligatoirement qu'ils 
soient instances d'une classe non abstraite, laquelle herite de la classe abstraite et rend 
non abstraites les proprietes et les operations abstraites. 

Graphique 

En UML 2.0, il n'existe pas de representation graphique particuliere pour les classes 
abstraites. En UM L 1.4, il fallait mettre le nom de la classe en italique. 

Multiplicity des proprietes etdes parametres 

Semantique 

1 1 est possible de preciser qu' une propriete ou un parametre peut porter pi usieurs valeurs. 
UML permetde preciser les nombres minimal et maximal deces valeurs. Preciser qu' une 
propriete peut avoir au minimum une valeur et au maximum une infinite de valeurs 
revienta preciser que la propriete est un tableau infini. 



Pour les proprietes et les parametres, les nombres minimal et maximal des valeurs appa- 
raissent entre crochets. Le caractere * est utilise pour preciser que le nombre maximal de 
valeurs est infini. 

La figure 2.14 presentedifferentes proprietes en precisant des nombres minimal et maxi- 
mal de valeurs. 



Graphique 



Figure 2.14 



Personne 



Representation 
graphique 



nom : string 

tel[1..4]:string 

prenom[l..*]:string 



des multi pi icites 
des proprietes 



getNom() 
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Visibility des classes, des proprietes etdes operations 

Semantique 

II est possible de preciser la visibilite des proprietes et des operations des classes. Les 
visibilites portent sur les acces aux proprietes et aux operations. On dit qu'une classeA 
accede a la propriete d'une classe B si le traitement associe a une operation deA utilise 
la propriete de B . On dit qu'une classeA accede a I' operation d'une classe B si le traite- 
ment associe a une operation deA fait un appel a I' operation de B. 

Les visibilites proposees par UM L 2.0 sont les suivantes : 

• public : la propriete ou I 'operation peuvent etre accedees par n'importe quelle autre 
classe. 

• private : la propriete ou I 'operation ne peuvent etre accedees que par la classe elle- 
meme. 

• protected : la propriete ou I' operation ne peuvent etre accedees que par des classes qui 
heritent directement ou indirectement de la classe qui definit la propriete ou I' opera- 
tion. 

Graphique 

Dans la representation graphique de I' element, les visibilites sont representees de la 
fagon suivante : 

• L e caractere + est utilise pour preciser la visibilite public. 

• Le caractere - est utilise pour preciser la visibilite protected. 

• Le caractere* est utilise pour preciser la visibilite private. 

Proprietes et operations de classe 

Semantique 

II est possible de preciser que la valeur d'une propriete definie par une classe est portee 
directement par la classe elle-meme (et non par chacun des objets). De meme, il est 
possible de preciser qu'une classe est directement responsable d'une operation qu'elle 
definit. On appel I eces proprietes etces operations des elements de niveau « classe ». 

Graphique 

Dans la representation graphique de la classe, les proprietes et les operations de niveau 
classe sont soulignees. 
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Chapitre 2 



Synthese 

Dans ce deuxieme chapitre, nous avons presents le diagramme de classes UM L qui 
permet de representer la vue structurelle des applications informatiques. Ce chapitre 
ne se veut pas un guide de reference du diagramme de classes. N ous avons simplement 
presente les concepts relatifs a ce diagramme dont nous aurons besoin dans la suite du 
cours. 

En introduisant ces concepts, nous avons detaille aussi bien leur semantique propre 
que la facon de la representer graphiquement. Rappelons que la semantique de ces 
concepts est proche de eel le des langages de programmation orientes objet sans lui 
etre equivalents. 

Pour finir, soulignons le fait que les diagrammes de classes UML peuvent etre 
employes a tout niveau d' abstraction. Rien n'empeche de representer une application 
informatique a I'aide d'une seule classe (haut niveau d' abstraction) ou de representer 
tous les composants de cette application comme des classes (bas niveau d'abstraction). 



Travaux d i r iges 

TD2. Diagrammes de classes 



Question 12 Definissez la classe UML representant un etudiant, caracterise, entre 
autres, parun identifiant, un nom, un prenom etune date de naissance. 

Question 13 Definissez la classe UML representant un enseignant, caracterise, entre 
autres, parun identifiant, un nom, un prenom etune date de naissance. 

Question 14 Definissez la classe UML representant un cours, caracterise par un identi- 
fiant, un nom, le nombre d'heures de cours magistral, le nombre d'heures 
de travaux diriges et un nombre d'heures de travaux pratiques que doit 
suivre un etudiant. 

Question 15 Definissez les associations qui peuvent exister entre un enseignant et un 
cours. 

Question 16 Definissez la classe UML representant un groupe d'etudiants en utilisant 
les associations. 

Question 17 Definissez I'association possible entre un groupe d'etudiants et un cours. 

Question 18 Pensez-vous qu'il soit possible de definir un lien d'heritage entre les classes 
UML representant respectivement les etudiants etles enseignants ? 

Question 19 Pensez-vous qu'il soit possible de definir un lien d'heritage entre les classes 
UML representant respectivement les etudiants etles groupes d'etudiants ? 
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Question 20 On nomme coursDeLEtudlantO I'operation permettantd'obtenir I'ensemble 
des cours suivis par un etudiant. Positionnez cette operation dans une 
classe, puis precisez les parametres de cette operation, ainsi que les 
modifications a apporter aux associations prealablement identifies pour 
que votre solution soit realisable. 

Question 21 On nomme coursDeLEnseignant( ) I'operation permettant d'obtenir 
I'ensemble des cours dans lesquels intervientun enseignant. Positionnez 
cette operation dans une classe, puis precisez les parametres de cette 
operation, ainsi que les modifications a apporter aux associations preala- 
blement identifies pour que votre solution soit realisable. 

Question 22 Expliquez le diagramme de classes represents a la figure 2.15. 



Figure 2.15 
Package planning 



planning 



Planning 



occupe 



Salle 



numero:integer 



Semaine 



numero:integer 



calculerC reneauxLibresO 



joursOuvrables 



Jours 



date:string 
nom:string 



ferie() 

calculerC reneauxLibresO 



7^ 



jours 



Creneau 



heureDebutstring 
heureFin:string 



Question 23 Positionnez tOUtes VOS Classes (Etudiant, Enseignant, Cours, 
GroupeEtudiant) dans un package nomme Personnel. 

Question 24 Liez vos classes pour faire en sorte qu'un creneau soit lie a un cours ! 
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Ce TD aura atteint son objectif pedagogique si et seulement si : 

• Vous maTtrisez la notion de classe. 

• Vous maTtrisez la signification des associations et heritages entre classes. 

• Vous avez compris la repercussion des associations entre classes sur les depen- 
dances entre packages. 
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Objectifs 

■ Preciser les differences semantiques entre modele UML (partie diagramme de 
classes) et code (Java) 

■ Presenter I'operation de Reverse Engineering et en identifier les gains et les limites 

■ Presenter la difference entre modele UML et diagramme UML 

Semantiques UML etj ava 

Comme indiqueau chapitre precedent, le langage UML est congu pour faciliter la cons- 
truction d'applications orientees objet. La premiere version decelangage, qui aetedefi- 
nie en 1995, a ete tres fortement influencee par les concepts des langages de programma- 
tion orientee objet de I'epoque, tels que C++, Smalltalk, etc. 

Les concepts UML de la partie relative au diagramme de classes, que nous avons presen- 
ted au chapitre precedent, sont done des concepts orientes objet. En particulier, les 
concepts de classe, de propriete, d' operation et de package sont partages par tous les 
langages de programmation orientee objet. 

A fin de bien souligner I' adequation du langage UM L au paradigme objet, il est interes- 
sant de rappeler que la premiere lettre de I'acronyme UML renvoie a U nified. Ce mot 
precise que le langage UML incarne I' unification de quasiment tous les langages de 
model isati on d'applications orientees objet. 
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Differences des semantiques 

Si U M L partage une semantique commune avec les langages de programmation orientee 
objet, cela ne veut pas dire qu'il ait exactement la meme semantique que ces langages. 

Comme chaque langage de programmation orientee objet, UML possede sa propre 
semantique, laquelle presente des differences significatives avec les semantiques des 
langages de programmation. N ous detail Ions dans cette section une parti e des differences 
entre la semantique UML et la semantique Java. Notre objectif est de montrer que les 
langages UML et J ava ont chacun leur propre semantique. 

Concepts UML inexistants dans les langages de programmation 

Association 

En Java, pour que des objets instances d'une classe A referenced des objets instances 
d'uneclasseB, il faut definir un attri but de type B dans la classe A. II est de pi us possible 
d'utiliser les tableaux Java afin qu'un objet instance d'une classe A reference plusieurs 
obj ets i nstances d' une cl asse B . 

Demanieresimilaire, UM L permetde definir une proprietede type B dans une classe A. II est 
aussi possible d'utiliser les multi pi i cites de cette propriete pour referencer plusieurs objets. 

Pour autant, le concept UM L d'association, que nous avons presente au chapitre prece- 
dent, n'existe pas en J ava, qui ne permet que de definir des references entre les classes, ce 
qui est different des associations. En particulier, en J ava, il n'estpas possible de preciser 
que deux references appartenant a deux classes correspondent a la meme association et 
que I ' une est I ' opposee de I ' autre. 

Import entre packages 

En Java, la notion de package n'existe qu'a travers la notion de classe. II n'est done pas 
possible de definir de package sans avoir au prealable defini une classe. II n'est pas non 
plus possible de definir des regies d'import entre packages, car, en Java, la relation 
d' import est toujours defini e entre une classe et un ensemble de classes qui peut etre 
identifie par un nom de package. 

En UM L, la notion de package existe independamment de la notion de classe. II est de 
plus possible, comme nous I'avons montreau chapitre precedent, de definir des relations 
d'importdirectement entre les packages. 

Direction des parametres 

En Java, les valeurs des parametres d'une operation sont toujours donnees par I 'appelant 
de I'operation. L'appele ne peut transmettre que la valeur de retour de I'operation. De 
plus, si un objet est transmis comme valeur de parametre par I 'appelant, l'appele peut 
changer les valeurs des attri buts de I'objet, mais non I'objet en lui-meme (il n'est pas 
possible deremplacer I'objet par un autre objet). 
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En UM L, les parametres d'une operation ont une direction (in, out, inout, return), qui 
precise la facon dont les valeurs doivent etre transmises. Dit autrement, Java nesupporte 
que les directions in et return d'UM L. 

Concepts des langages de programmation inexistants en UML 

Corps des methodes 

Les langages de programmation permettent tous de coder le traitement associe a chaque 
operation. C'est d'ailleurs la que reside la logique de I 'application. Curieusement, UML 
ne permet pas (voir encadre) de definir le traitement associe aux operations des classes. 
Nous verrons neanmoins dans la suite de ce chapitre comment integrer directement dans 
le modele U M L des morceaux de codej ava pour pallier ce probleme. 



Traitements associes aux operations UML 

II est de plus en plus possible de definir en UML les traitements associes aux operations, notamment a 
I'aide de langages tels que OCL (Object Constraint Language) ou ActionSemantic. Cela reste toutefois un 
travail de recherche, dont les resultats ne sont pas encore disponibles dans les outils UML du marche. 
Dans le cadre de ce cours, nous considerons done qu'il n'est pas possible de definir en UML les traite- 
ments associes aux operations. 



Semantique d'appel d'operation 

Chaque langage de programmation definit sa propre semantique d'appel d'operation. En 
Java, parexemple, les operations sont appelees de maniere synchrone, I'appelant devant 
attendre la fin du traitement associe a I'operation avant de pouvoir faire quoi que ce soit 
d' autre. 

II est cependant possible de realiser en J ava des appels asynchrones en utilisant le meca- 
nismede thread. En UML, aucune semantique d'appel d'operation n'est imposee. Celle- 
ci n'apparatt pas dans la partie structurelle du modele. Nous verrons au chapitre 6 qu'il 
est possible de modeliser differentes semantiques d'appel d'operation dans la partie 
comportementale du modele. 

API 

Chaque langage de programmation dispose de sa propre A PI (A pplication Programming 
Interface). C'est d'ailleurs cequi fait la richessedu langage de programmation. 

Java dispose d'uneAPI parti culierement riche, qui permet, entre autres choses, d'appli- 
quer des operations arithmetiques elemental res, d'envoyer des messages sur Internet, 
d'ecrire et de lire dans des fichiers et d'afficher des composants graphiques. 

UML ne propose aucune A PI. II est d'ailleurs impossible de modeliser en UML Impli- 
cation HelloWorld, car il n'existe aucune A PI permettant d'afficher unechamedecarac- 
teresa I'ecran (equivalantdu system. out. printin dejava). 
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Concepts communs a UML etaux langages de programmation 
qui n'ontpas le meme sens 

Heritage 

En Java, seul I ' heritage simple entre classes est autorise. II n'est done pas possible de 
faire en sorte qu'une classe herite de plusieurs classes. II est toutefois possible d'utiliser 
I e concept J ava d' interface, puisqu'une classe J ava peut realiser plusieurs interfaces J ava. 
En UM L, I ' heritage multiple est autorise. 

Types de base 

Comme tout langage de programmation, Java possede un ensemble relativement fourni 

de types de base (byte, short, int, long, float, double, boolean, char). A Cet ensemble 

peuvent s'ajouter d'autres types definis dans I * A PI , tels que le type string. Depuis 
Java 1.5, il est en outre possiblededefinirdestypesenumeres. 

UM L ne propose pour Sa part que peu de types de base (integer, String, Boolean, Char, 

Real). La raison a cela est que, historiquement, UM L a etecongu pour etre un langage de 
moderation. II n'etait done pas necessaire d'avoir un systeme de typage aussi fin que 
dans un langage de programmation. 

Synthese entre UML et les langages de programmation 

Nous venons de monter que U M L et J ava presentaient des similitudes aussi bien que des 
differences de semantique. Cette relation entre UML et Java vaut d'ailleurs pour 
n'importe quel autre langage de programmation. 

La figure 3.1 represente une parti e des similitudes et divergences des semantiquesj ava et 
UM L, qui se revel eronttres importantes dans la suite de notre cours. 



Schematisation 
de la relation 
existant entre 
les semantiques 
UML etjava 




Passage de code J ava vers les diagrammes de classes 

Avant de presenter la fagon dont nous pouvons construire automatiquement un 
diagramme de classes a partir d'un programme Java, il est important de bien preciser 
I'objectif de I'operation de Reverse Engineering. 
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Rappelons d'abord ceque nous avons deja indiqueaux chapitres precedents, a savoir que 
le code n'est que la materialisation de la solution. Notre objectif, quand nous voulons 
construire un diagramme de classes a parti r du code, est de construire le modele de la 
solution a partir desa materialisation. 

Le fait de ne construire que le diagramme de classes implique que nous ne construisons 
qu'une partie du modele de la solution, en I'occurrence la partie structurelle de cette 
solution. De plus, le fait que le diagramme de classes represente scrupuleusement la 
structuration du code fait que nous ne ciblons que le niveau d'abstraction le plus bas, 
comme nous le verrons plus precisementdans la suite de cette section. 

Par rapport a notre representation schematique du modele d'une application informati- 
que, I 'operation de Reverse Engineering permet de construire automatiquement la partie 
du modele de I 'application relative a la vue structurelle etcibl ant I e niveau d'abstraction 
le plus bas. 

La figure 3.2 presente cette proprietedu Reverse Engineering. 



Figure 3.2 

Code, modele 
et operation 
du Reverse 
Engineering 
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L' operation de Reverse Engineering permet uniquement de construire une parti e du 
model e ( parti e structurelle au niveau d' abstraction I e plus bas), qui permet, en quel que 
sorte, de « mettre un pied » dans le model e. Son interet est, avant tout, d'etablir un lien 
entre le code et le model e. Le code est lie au model e grace a cette relation. 

Les relations de coherence avec les autres parties du model e permettent de lier, par tran- 
sitivite, le code avec I ' i ntegral ite du modele. Precisons que le Reverse Engineering ne 
permet en aucun cas de construire automatiquement I'i ntegralite du modele. 

Regies de correspondance du Reverse Engineering 

L' operation de Reverse Engineering que nous envisageons consiste a construire la parti e 
structurelle du modele UM L au plus bas niveau d' abstraction a parti r du code Java d'une 
application. 

Pour pouvoir realiser cette operation automatiquement, il faut definir et implanter des 
regies de correspondance entre les concepts Java et les concepts UML. Ces regies de 
correspondance sonttres complexes, car elles etablissent une correspondance semanti que 
entre J ava et U M L (pont semanti que). 

Nous presentons dans cette section un sous-ensemble de regies d'une correspondance 
possible entre J ava et U M L . N ous considerons que cet ensemble de regies de correspon- 
dance definit I 'operation de Reverse Engineering de notre cours. Dans la suite du cours, 
lorsque nous parlerons de I 'operation de Reverse Engineering, nous nous refererons 
implicitement a cet ensemble de regies de correspondances. 

Regies de correspondance J ava vers UML 

1. A toute classejava doit correspondre une classe UM L portant le meme nom que la 
classejava. 

2. A toute i nterfacej ava doit correspondre une i nterfaceUM L portant le meme nom que 
I 'interface J ava. 

3. A tout attri but d'une classe Java doit correspondre une propriete appartenant a la 
classe UM L correspondant a la classejava. Le nom de la propriete doit etre le meme 
quelenom del'attribut. Letypede la propri ete doit etre une correspondance U M L du 
type de I 'attri but Java. Si I 'attri but est un tableau, la propriete peut avoir plusieurs 
valeurs (en fonction de la taille du tableau). 

4. A toute operation d'une classejava doit correspondre une operation appartenant a la 
classe UM L correspondant a la classejava. Le nom de I 'operation UML doit etre le 
meme que celui de I 'operation Java. Pour chaque parametre de I 'operation Java doit 
correspondre un parametre UM L de meme nom, dont la direction est in et dont le 
type est I e type U M L correspondant au ty pe du parametre J ava. 

5. Si une classe J ava appartient a un package J ava, ce dernier doit correspondre a un 
package UML correspondant au package Java qui doit contenir la classe UML 
correspondant a la classejava. 
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6. Si une classejava importe un package Java, ce dernier doit correspondre a une rela- 
tion d' import entre le package U M L de la classe U M L correspondant a la classej ava 
et le package U M L correspondant au package J ava importe. 

7. Si une classejava herite d'une autre classejava, les classes UML correspondantes 
doivent avoir elles aussi une relation d'heritage. 

8. Si une classejava realise une interface, la classe UML correspondante doit aussi 
real i ser I ' i nterf ace UML correspondante. 

Ces regies de correspondance ne prennent pas en consideration le concept UM L d'asso- 
ciation. Cela n'est pas surprenant puisque ce concept n'existe pas en Java. Cependant, 
nous pouvons considerer qu'il est possible de construire une association dans le modele 
UML plutot qu'une propriete lorsqu'une classej ava reference une autre classe J ava. 

La regie n° 3 deviendraitalors : 

A tout attri but d'une classej ava dont le type est un type primitif doit correspondre une 
propriete appartenant a la classe UML correspondant a la classejava. Le nom de la 
propriete doit etre le meme que le nom de I'attribut. Le type de la propriete doit etre 
une correspondance UML du type de I'attribut Java. Si I'attribut est un tableau, la 
propriete peut avoir plusieurs valeurs (en fonction de la taille du tableau). 

A tout attribut d'une classejava dont le type est une autre classejava doit corres- 
pondre une association UML entre la classe UML correspondant a la classejava de 
I'attribut et la classe UM L correspondant au type de I 'attri but J ava. Cette association 
doit etre navigable vers la classe UML correspondant au type de I ' attri but J ava. Le 
nom de role de la classe correspondant au type de I'attribut doit etre le meme que le 
nom de I 'attri but J ava. Si I ' attri but J ava est un tableau, I'extremitede I'association qui 
porte sur la classe UML correspondant au type de I ' attri but J ava doit specifier que 
plusieurs objets peuvent etre lies. Sinon, nous considerons que la multi pi i cite est 0..1. 

Pour finir, soulignons que les regies de correspondance que nous venons d'indiquer ne 
prennent pas en consideration le code des traitements associe aux operations J ava. Cela 
n'est pas surprenant puisque ce concept n'existe pas en UM L. Cependant, il est absolu- 
ment necessaire d'integrer le code d'une maniere ou d'une autre dans le modele UML 
afin de pouvoir le reutiliser dans le cadre de I 'operation de generation de code que nous 
detail Ions au chapitre 5. 

Pour cefaire, nous proposons d'integrer le code des traitements associes aux operations 
sous forme de note UM L. Ce mecanisme est utilise par quasi menttous les outi I leurs du 
marche. A insi, cette derniere regie s'ajoute a notre ensemble de regies composant notre 
Reverse Engineering : 

9. Si une operation J ava possede un code de traitement, alors doit correspondre une note 
UML contenant ce code et qui doit etre attachee a I'operation UML correspondant a 
I'operation Java. 

Etant donne que les semantiques de UM L etjava different, soulignons I e fait qu'il existe 
plusieurs regies de correspondance possibles. En fait, chaque outil UML du marche 
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propose sa propre operation de Reverse Engineering, avec ses propres regies de corres- 
pondence (tres souvent, ces regies ne sont d'ailleurs pas expl icitees). C'est pourquoi, a 
parti r d'un meme programme J ava, il est possible d'obtenir plusieurs model es UML 
differents. 



Interetet I i mites du Reverse Engineering 

En debut de chapitre, nous avons presente le Reverse Engineering comme une operation 
permettant de construire des diagrammes de classes a parti r de code J ava. Nous savons 
maintenant que cette operation permet en fait la construction automatique d'une parti e du 
modele UM L (partie structurelle de bas niveau d' abstraction) a parti r decode J ava. 

UML fait la distinction entre modele UM L et diagramme UML. Un diagramme n'est 
qu'une representation graphique d'une partie d'un modele. II est des lors possible de 
definir plusieurs diagrammes pour un meme modele. 
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Figure 3.3 

M odele U M L d'une application i nformatique et ses diagrammes 
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Les diagrammes represented graphiquement 1'information contenue dans un model e. 
L'operation de Reverse Engineering neconstruit done pas dediagrammede classes mais 
une parti e du model e. Nous pouvons considerer que l'operation de Reverse Engineering 
construit la partie structurelle du modele et la stocke dans une base de donnees ou dans 
un fichier. Grace aux informations contenues dans la base de donnees ou dans lefichier, 
il est possible de construire plusieurs diagrammes de classes. 

Selon notrevueschematiquedu modele d'une application informatique, lemodeleUM L 
d'une application correspond a I'ensemble des informations contenues dans les neuf 
parties du modele UM L que nous avons presentees au chapitre 1. 

De plus, UML fait correspondre un type de diagramme particulier pour chacune des 
vues. Par exemple, nous avons donne au chapitre precedent le diagramme de classes 
correspondant a la vue structurelle d'une application. Nous presenterons dans la suite de 
ce cours les diagrammes correspondant aux vues comportementale et fonctionnelle. 
UM L ne donne aucune consigne quant au nombre de diagrammes qu'il faut elaborer 
pour presenter chacune des neuf parties du modele. 

La figure 3.3 synthetise cette distinction entre vue et diagramme et montre qu'il est 
possible d' elaborer plusieurs diagrammes par partie du modele. 

Diagrammes a faire apres un Reverse Engineering 

Puisque l'operation de Reverse Engineering neconstruit pas de diagramme mais unique- 
ment une partie du modele U M L, il estdu ressort dela personnequi a execute le Reverse 
Engineering d' elaborer les diagrammes permettant de representer graphiquement les 
informations obtenues. 

Apres avoir realise une operation de Reverse Engineering, nous preconisons done 
d' elaborer les diagrammes suivants, qui permettent de representer graphiquement les 
informations contenues dans la partie du modele obtenue apres Reverse Engineering : 

• un diagramme de classes representant I' integral ite des informations ; 

• un diagramme de classes representant uniquement I'ensemble des packages et leurs 
relations d' import sans montrer leur contenu ; 

• un diagramme par package montrant uniquement le contenu d'un package; 

• un diagramme par classe permettant de montrer le contenu de la classe et les associa- 
tions et les liens d' heritage vers les autres classes. 

Gains offerts par le Reverse Engineering 

Le Reverse Engineering est I a premiere operation de model isati on qui permetted'obtenir 
un gain de productivite. En permettant de generer automatiquement une des neuf parties 
du modele UM L, il off re, a moindre cout, les deux avantages suivants : 

• Possi bi I ite de generer une documentation de la structure de Implication a I'aide des 
diagrammes de classes elabores. Cette documentation a I 'avantage d'etre faitedans un 
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langage de model isati on standard tres largement diffuse. Soulignons de plus que de 
nombreux outils du marche qui proposent une operation de Reverse Engineering 
proposent une operation de generation automatique de documentation. U ne documen- 
tation UML tres technique peut done etre obtenue rapi dement. 

• Possibility d' el aborer lesautres parties du modele UM L tout en gardant une coherence 
avec le code. C'est d'ailleurs le principal atout du Reverse Engineering que de 
permettre d'elaborer le lien entre une application existante et un model e. Cette opera- 
tion est absolumentfondamentalelorsque nous voulonsobtenir, a parti r d' une applica- 
tion existante, les gains de productivity des operations de modelisation que nous 
detaillons dans les chapitres suivants dececours. 



Synthese 

Dans ce troisieme chapitre, nous avons commence par presenter les differences 
semantiques entre le langage UM L et les langages de programmation orientee objet. 
Cela nous a permis de bien preciser le fait qu'UM L possedait sa propre semantique, 
qui est une semantique orientee objet, mais aussi ses propres particularites. 

Nous avons ensuite detaille les principes de I 'operation de Reverse Engineering. Cette 
operation est un pont semantique entre un langage de programmation et le langage 
UML. Tout en soulignant le fait qu'il pouvait exister differents ponts semantiques, 
nous avons indique une fagon de passer du code J ava vers les diagrammes de classes. 
Cette fagon de passer de Java a UM L constitue I 'operation de Reverse Engineering 
que nous utiliserons dans la suite de ce cours. 

Pour finir, nous avons introduit la distinction entre les concepts de modele UM L et de 
diagramme UM L. Nous avons en particulier insistesur lefait qu'un diagramme n'etait 
que la representation graphique de I'information contenue dans un modele. De cefait, 
le Reverse Engineering est une operation qui permet la construction d'une partie du 
modele mais qui ne genere aucun diagramme. Nous pouvons considerer que le modele 
est stocke dans une base de donnees ou dans un fichier. L'elaboration des diagrammes 
restea la charge de la personne qui a execute I'operation de Reverse Engineering. 

Nous avons enfin degage les avantages offerts par le Reverse Engineering, notamment 
les deux suivants : permettre de generer tres facilement la documentation technique 
structurelle d'une application existante et permettre d'etablir un lien entre le code 
d'une application et le modele de I ' appl icati on. 



Reverse Engineering 



Travaux diriges 

TD3. Reverse Engineering 



Chapitre 3 



Les operations de Reverse Engineering presentees dans ce TD portent sur le code Java 
de I'application MyAssistant donne au TD du chapitre 1. Nous appliquons ici les regies de 
correspondance Java vers UML decrites dans le present chapitre. 

Question 25 Effectuez le Reverse Engineering de la classe Adresse. 

Question 26 Effectuez le Reverse Engineering de la classe Personne, 

Question 27 Effectuez le Reverse Engineering de la classe Repertoire. 

Question 28 Pourquoi n'y a-t-il pas d'association entre la classe Repertoire et la classe 
Personne alors qu'un repertoire contientdes personnes ? 

Question 29 Comment modifier les regies du Reverse Engineering pourfaire en sorte 
qu'une association soit etablie entre la classe Repertoire et la classe 

Personne ? 

Question 30 Effectuez le Reverse Engineering de la classe uiPersonne. 

Question 31 Comment introduire les classes Java dans le modele UML ? A quoi cela 
sert-il ? 

Question 32 Est-il plus facile de comprendre une application apres en avoir effectue le 
Reverse Engineering ? 

Question 33 Les informations obtenues apres Reverse Engineering sont-elles plus 
abstraites que le code J ava ? 

Question 34 Le modele obtenu par Reverse Engineering contient-il plus de diversite 
que le code ? 

Question 35 Si vous aviez un modele UML et le code Java correspondant, comment 
pourriez-vous savoirsi le modele UML a ete construita partird'un Reverse 
Engineering ? 



Ce TD aura atteint son objectif pedagogique si et seulement si : 

• Vous savez appliquer une operation de Reverse Engineering sur un code pas trap 
complexe. 

• Vous avez compris les conditions d'etablissement d'associations entre classes. 

• Vous avez conscience que le modele obtenu apres Reverse Engineering ne vous 
apporte hen de plus que le code, si ce n'est d'avoir fait le premier pas vers I'obten- 
tion d'un modele complet de votre application. 



4 

Retroconception 
et patrons de conception 



Objectifs 

■ Definir la notion de dependance entre classes et preciser les mecanismes de retroconception 

■ Presenter les patrons de conception 



Identification des dependances 

L'operation de R everse E ngi neeri ng presentee au chapi tre precedent permet de construi re 
automatiquement une parti e du model e d'une application existante. Nous avons deja 
indique qu'un des avantages de cette operation etait de permettre la generation de docu- 
mentation. Cet avantage est certes tres interessant mais reste en quelque sorte 
« contemplatif », lemodeleobtenu n'etant pas considerecommeun element de producti- 
vity a part entiere. II n'est done pas interessant de produire du code apres un Reverse 
Engineering. 

L' autre avantage de l'operation de Reverse Engineering est de permettre I'etablissement 
d'un lien entre I e code et I e model e, afin que des operations de productivity sur les mode- 
les puissent etre real i sees, en prenant garde de ne pas detruire la coherence entre le 
modeleetlecode. 

Nous al Ions a present detainer deux operations de productivite que nous pouvons real iser 
sur les model es obtenus apres Reverse Engineering. Le but de la premiere operation est 
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de verifier et corriger les dependances entre les classes. Celui de la seconde est d'appli- 
quer des solutions de conception largement connues a des problemes deja identifies. 

Ces deux operations sont dites productives en ce qu'elles changent le modele. II est des 
lors interessant de produire du code apres les avoir ex ecutees. 

Qu'est-ce qu'une dependance ? 

Avant de preciser techniquement ce qu'est une dependance entre deux classes UM L, il 
est important de rappeler I 'essence memede ce terme. Le dictionnaire de la I angue fran- 
chise en ligneTLFI (Tresor de la langue frangaise informatise) donne les definitions 
suivantes du mot « dependance » (http://atiif.atiif.fr/tif.htm) : 



Dependance : fait d'etre lie organiquement ou fonctionnellement a un ensemble ou a un element d'un 
ensemble. 



Applique a notredomaine, cela signifie qu'une classeA depend d'uneclasse B si el I e est 
lieesoit organiquement (par I'unedeses proprietesou I'unedeses associations) ou fonc- 
tionnellement (par I'unedeses operations) a un ensemble de classes ou a une classe d'un 
ensemble de classes. 

De plus, si une classeA depend d'une classe B, cela signifie qu'il n'est pas possible 
d'utiliser la classeA pour, par exemple, instancier des objets sans disposer de la classe B. 
La relation de dependance etant transitive (si A depend de B et B depend de C alors A 
depend de C ), nous mesurons toute I ' i mportance des dependances dans I e devel oppement 
d' applications orientees objet. 

D'un point de vue technique, nous considerons dans le cadre de ce cours qu'une classeA 
depend d'une classe B si etseulementsi : 

• A herite de B . 

• A est associee a B, et I 'association est au moins navigable deA vers B. 

• A possedeun attri but dontle type est B. 

• A possedeuneoperationdontletypedel'undesparametresestB. 

D'un point de vue graphique, une dependance entre deux classes se represente a I 'aide 
d'une fleche pointillee. La figure 4.1 represente graphiquement une dependance entre la 
classeA et la classe B. 



Figure 4.1 

Representation 
graphique d'une 
dependance entre 
deux classes 
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Cette representation ne precise pas quelle est la cause de cette dependance. La figure 4.2 
fournit chacune des causes possi bles. 

Figure 4.2 

Representation 
g ra phi que 
des causes 
d'une relation 
dedependanceentre 
deux classes 



A 




A 


-b : B 




operation(in b : B) 



Soulignons qu'il est possible de faire apparaitre sur un meme diagramme les relations de 
dependance et I es causes des relations de dependance. Par souci declarte, nous preferons 
toutefois privilegier I'elaboration d'un diagramme dedie aux dependances et masquant 
les causes des dependances. L'objectif d'un tel diagramme est de faire ressortir unique- 
ment les relations de dependance entre les classes d'une application. 

Impact des cycles de dependances 

Dependances entre classes 

Nous avons donnea la section precedente la definition de la dependance entre deux clas- 
ses. Le caractere principal de cette relation est que, si uneclasseA depend d'une classe 
B, il n'est pas possible d'utiliser A sans disposer de B . La question surgit des lors de 
I'interet des dependances mutuelles, et plus general ement des cycles de dependances. 

Si deux classes A et B dependent mutuellement I'une de I'autre, cela signifie qu'il est 
impossible de les separer. Nous pouvons legitimement nous demander s'il n'est pas inte- 
ressant de fusionner les classes, puisque la dependance mutuelle va a I'encontre des deux 
principes de base du paradigme objet que sont la coherence forte et le couplage faible. 
Ces deux principes visent a definir des objets relativement independants (couplage 
faible) et capables de real iser par eux-memes les operations dont ils sont responsables 
(cohesion forte). L'objectif est de reutiliser des classes dans differentes applications. 

En real ite, il ne faut pas considerer que la dependance mutuelle ou les cycles de depen- 
dances represented des fautes de conception. II est parfois necessaire, voire obligatoire, 
d'etablir des dependances mutuelles afin d' assurer une navigation bidirectionnelle entre 
des elements lies. 

La figure 4.3 presente une association navigable dans les deux sens entre les classes 
Personne et compteBancai re. Cette association est la cause d'une dependance mutuelle 
entre ces deux classes. Pourautant, nous comprenons aisement qu'il serait interessant de 
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pouvoir naviguer dans les deux sens de cette association, mais nous comprenons aussi 
tout I'interet de garder ces deux classes et de ne pas les fusionner. 



Personne 



nom : string 

tel[1..4]:string 

prenom[l..*]:string 



getNomO 



ti tula ire 



moyens de paiement compteCourant 



^> CompteBancaire 



Figure 4.3 

Representation graphique d'une dependance mutuelle entre deux classes 

Dans le cadre de ce cours, nous considerons qu'il faut reduire autant que possible les 
dependances mutuelles et les cycles de dependances entre classes mais qu'il n'est pas 
necessairede les interdire. 

Dependances entre packages 

Comme nous I'avons vu au chapitre 2, il est necessaire d'etablir une relation d'import 
entre deux packages lorsqu'il existedes associations ou des relations d' heritage entre les 
classes qu'ils contiennent. 

II est en fait necessaire d'etablir une relation d'import entre deux packages s'il existedes 
dependances entre les classes qu'ils contiennent, et ce quelle qu'en soit la cause. 

La figure 4.4 illustre I e fait qu'il est necessaire d'etablir une relation d'import entre PI et 
P2, car A depend deB,A appartient a PI et B appartient a P2. II est en outre necessaire 
d'etablir une relation d'import entre P2 et P3, car B depend de C, B appartient a P2 et C 
appartient a P3. 

Figure 4.4 

Dependances 
entre packages 



pl 






A 




b : B 
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De ce fait, il semble possible d'avoir a etablir des relations d'import mutuel entre deux 
packages (par exemple, si la classe C herite deA ). Or, comme indique au chapitre 2, nous 
interdisons dans le cadre de ce cours les cycles d'import entre packages parce que nous 
considerons qu'un package represente une unite de cohesion entre plusieurs classes. De 
ce fait, s'il existait une relation d'import mutuel entre deux packages, cela signifierait 
qu'il faudrait reunir ces packages. 

Dans I e cadre de ce cours, les dependances mutuel les et plus general ement les cycles de 
dependances entre classes sont interdits entre les classes de plusieurs packages. 

Casser les cycles de dependances 

Dans les deux sections precedentes, nous avons presente I e concept de dependance entre 
classes en precisant qu'il etait envisageable d' etablir des cycles de dependances tant que 
ceux-ci ne traversaient pas plusieurs packages. 

Pour autant, il n'est pas rare de devoir concevoir une application devant obligatoirement 
definir deux packages et dont les classes de ces deux packages ont des dependances 
mutuel les. 

La figure 4.5 illustreceproblemeavec deux classes et deux packages. 



Figure 4.5 
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A *■ 
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Ce probleme de conception relativement classique necessite de casser I e cycle des depen- 
dances. Avantd'introdui re le mecanismequi permet de casser les cycles de dependances, 
il est necessaire de souligner le point suivant : 



Une dependance mutuelle indique un besoin mutuel entre plusieurs classes. Ce besoin est reel et ne peut 
etre supprime. Casser un cycle de dependances ne signifie done pas changer les besoins entre les clas- 
ses. 



Ce point etant souligne, nous pouvons detainer le principe de base du mecanisme 
permettant de casser un cycle de dependances. L'idee general e est de travail ler sur une 
dependance parti culi ere et de changer cette dependance en une indirection a I' aide d'une 
nouvelle classe et d'une relation d' heritage. 

Ce principe est illustre a la figure 4.6. La parti e du haut presente la dependance initial e 
sur laquelle va s'effectuer I'indirection. La partie du bas presente I' indirection. Soul i- 
gnons que le besoin source de la dependance n'a pas ete supprime. II a si mpl ement ete 
i so I e et deplace dans la classe BSup. 
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Figure 4.6 

M ecanisme 
de suppression 
d'un cycle 
de dependances 



B contient quelque chose 
dont A a besoin 




On deplace le 
besoin dans BSup 



Grace a ce principe, il n'existeplus de dependance directe entre les classes A et B . II est 
des lors possible d'avoir deux packages PI et P2 avec les classes A et B danschacun des 
deux packages sans avoir d'import mutuel entre les packages PI et P2. 

Nous pouvons done avoir la relation de dependance entre B etA i 1 1 ustree a la figure 4.7. 



Figure 4.7 

Suppression 
d'un cycle 
de dependances 
entre packages 



Pi 



BSup 

I 
I 



P2 



Pour pouvoir appliquer ce principe sur n'importe quel model e, il est necessaire de proce- 
der de la facon suivante : 

1. Identifier la dependance sur laquelle peut se faire I'indirection (cette dependance ne 
peut avoir un heritage comme cause). 

2. Isoler le besoin de la dependance dans une superclasse afin de deplacer la depen- 
dance. Parexemple, si A depend deB car A utilise une operation de la classe B , il faut 
positionner cette operation dans la superclasse afin de pouvoir deplacer le lien de 
dependance. 
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3. Etablir la relation d'heritage. 

4. Positionner les classes dans les packages et mettre les bonnes relations d'import. 

Ce mecanisme en quatre etapes peut paraTtre trivial, mais il ne I'est en rien. La difficulty 
principaleestde pouvoir isoler dans unesuperclasse le besoin d'une dependance afin de 
permettre la creation d'une indirection. 

Cette operation de productivite est tres souvent executee apres I' execution d'une opera- 
tion de Reverse Engineering. Rappelons que son objectif est de renforcer le couplage 
fai bl e entre I es cl asses et de real i ser une decoupe en package de mei 1 1 eure qualite, dans I a 
mesureou Java n'interdit pas les imports mutuels entre packages. 



Patron de conception 

En conception, il n'est pas rare de fai re face a un probleme qui a deja ete rencontre et 
resolu par d'autres personnes. Reutiliser les solutions trouvees par ces autres personnes 
permet de gagner non seul ement du temps mai s aussi de I a qualite, pour peu que ces solu- 
tions aient ete largement diffusees et corrigees d'eventuelles erreurs. 

Pour rendre cette idee concrete, E. Gamma a defini le concept de patron de conception. 
Un patron de conception est une solution eprouveequi permet de resoudre un probleme 
de conception tres bien identified Soulignons qu'un patron de conception est un couple 
<probleme/solution>. 

La solution defi nie par un patron de conception n'est interessante que si nous fai sons face 
au meme probleme que celui traite par le patron. II nefauten aucun cas vouloir appliquer 
les solutions definies par les patrons de conception si nous n'en rencontrons pas les 
probl ernes. 

E. Gamma a defini plus d'une vingtainede patrons de conception de reference, qui sont 
toujours utilises a I'heure actuelle. Depuis lors, le nombre de patrons de conception 
reconnusnecessed'augmenter. Decefait, il est tres important aujourd'hui, lorsquenous 
fai sons face a un probleme de conception, de verifier si un patron de conception n'a pas 
deja ete defini pour traiter ce probleme. 

Le point qui nous interesse dans le cadre de ce cours est que la solution defi nie par un 
patron est specifiee a I'aide d'un diagramme de classes. Les classes de ce diagramme 
represented des roles qu' i I est necessai re de fai re j ouer par certai nes cl asses de I ' appl i ca- 
tion. Appliquer la solution definie par un patron de conception sur une application 
consiste done a identifier parmi les classes de I ' appl i cati on lesquel les doivent jouer les 
roles defini s par la solution. 

Le patron de conception Observer 

Afin de bien i 1 1 ustrer le concept de patron de conception, nous al Ions detainer le patron 
de conception Observer tel que defini par E. Gamma. 
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Observer 

Probleme 

Creer un lien entreun objet « source » etplusieurs objets « cibles » permettantdenotifier 
les objets « cibles » lorsque I'etat de I 'objet « source » change. De plus, il faut pouvoir 
dynamiquement lier a (ou del i er de) I 'objet « source » autantd' objets « cibles » que nous 
le voulons. 

Solution 

La solution dece patron est i 1 1 ustree a la figure 4.8. 



Figure 4.8 

Le patron 
de conception 
0 bserver 



Subject 



attach(in obs : Observer) 
detach(in obs : Observer) 



rjQtifyO 



TV 



observer 



ConcreteSubject subject 



state 



getStateO 
setState() 



for all observer { 
update() 

} 



Observer 



+update() 

TV" 



ConcreteObserver 



+update() 
1 



subject. gets tate() 



Cediagrammefaitapparaitre les quatre roles suivants : 

• Le role observer est un role abstrait (la classeestabstraite) qui represente une abstrac- 
tion de I'objet « cible ». Sa methode update permetde lui envoyer un message de noti- 
fication dechangement d'etat de I 'objet « source ». 

• Le role subject est un role abstrait qui represente une abstraction de I'objet « source ». 
L'association entre les classes subject et observer exprime le fait qu'un objet 
« source » peut etre lie a plusieurs objets « cibles ». Grace aux operations attach et 
detach, il est possible dynamiquement de lier et de deli er les objets « cibles ». Lorsque 
nous appelons I'operation notify, I'objet « source » appelle les operations update des 
objets « cibles » auxquels il est lie. C'est decette maniere que se fait la notification du 
changement d'etat de I'objet « source » vers tous les objets « cibles ». 

• Le role ConcreteSubject est un role concret qui herite de subject. II represente I'objet 
« source » avec son etat. Cela n'apparatt pas sur lediagramme, mais, a la fin du traite- 
mentassociea I'operation setstate, il fautfaireun appel a I'operation notify si I'etat 
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de I ' obj eta change. Cela permet, comme nous I'avons deja indique, de notifier tous les 
objets « cibles » du changement d'etat. 

• Le role concreteObserver est un role concret qui heritede observer. L'association entre 
les classes ConcreteObserver et concreteSubject expri me le fait qu' un objet « cible » est 
lie a I'objet « source ». Cela permet a I' objet « cible » de recuperer, apres notification, 
la nouvelle valeur de I'etat de I'objet « source ». 

Appliquer ce patron de conception sur une application necessite d' identifier dans le 
modele de I ' appl i cati on les classes pouvant jouer les roles de subject, observer, 
ConcreteSubject et ConcreteObserver. Si aucune classe existante ne peut jouer un des roles 
du patron de conception, il est envisageable de construire une nouvelle classe dans le 
modele. 

L'application des patrons de conception est une operation de productivite qui est tres 
souvent employee sur les model es. Cela permet de fournir des solutions eprouvees aux 
probl ernes de conception qui ont deja ete rencontres par d'autres personnes. 



Synthese 

Dans ce chapitre, nous avons presente deux operations de productivite sur les model es 
UML. 

La premiere a consiste a identifier les cycles de dependances entre les classes et a les 
casser s'ils traversaient plusieurs packages. Cette operation permet d'ameliorer la 
qualite de l'application en assurant un couplage faible entre les classes de 
l'application. 

La seconde a consiste a appliquer des patrons de conception. Grace a ces derniers, il 
est possible de reutiliser les bonnes solutions permettant de resoudre des problemes 
deja rencontres. 

Ces deux operations laissent entrevoir les gains offerts par UM L. Cependant, el les ne 
sont reellement interessantes que s'il est possible de generer du code a parti r du 
modele UML apres les avoir executees, puisque les deux operations changent le 
modele. Celui-ci n'etant plus coherent avec le code de l'application, il est necessaire 
d' actual iser le code a parti rdu modele. 

C'est ce que nous verrons au chapitre suivant, qui presente la generation de code a 
parti rde model es UML. 
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Travaux d i r iges 

TIM. Retroconception 
et patrons de conception 

La figure 4.9 represente les relations qui existent entre les classes Synchronisateur et 
Cal cul ateur. Un calculateur permet d'effectuer des calculs. Etant donne que n'importe qui 
peut demander a un calculateur d'effectuer des calculs, la classe Synchronisateur a ete 
construite pour reguler les calculs. 

Les personnes qui souhaitent demander la realisation d'un calcul doivent passer par le 
synchronisateur (via I'operation calculer-O). Celui-ci distribue les calculs aux differents 
calculateurs avec lesquels il est lie (c'est lui qui appelle I'operation calculerfj sur les 
calculateurs). Un calculateur connaTt le synchronisateur auquel il est relie grace a la 
propriete sync de type Synchronisateur. Sa valeur doit etre determinee lors de la creation 
des objets de type Cal cul ateur. 



Figure 4.9 
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Synchronisateur 


calculateur 


Calculateur 
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-sync : Synchronisateur 


+calculer() 
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Exprimez en les justifiant les dependences entre les classes Synchronisateur 
et Cal cul ateur. 

Nous souhaitons que les classes Synchron isateur et Cal cul a teur soient dans 
deux packages differents. Proposez une solution. 

Nous souhaitons ajouter a la classe Synchronisateur une operation 
ajouterCal cul ateur ■() qui permette d'assigner un calculateur a un synchroni- 
sateur, I'identite du calculateur etant un parametre d'entree de I'operation. 
Definissez cette operation. 

Nous souhaitons maintenant definir une classe representant une barre de 
progression. Cette barre affiche I'etat d'avancement du calcul (en pourcen- 
tage). Une barre de progression regoit des messages d'un calculateur qui 
I'informe que I'etat d'avancement du calcul a change. Definissez cette 
classe. 

Tout comme le synchronisateur, une barre de progression doit se declarer 
aupres d'un calculateur. De plus, le calculateur doit offrir une operation 
permettant de connaftre le pourcentage d'avancement du calcul. Definissez 
les associations et operations necessaires. 

Appliquez le patron de conception Observer, et faites en sorte que ces deux 
classes soient dans deux packages differents. 
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Ce TD aura atteint son objectif pedagogique si et seulement si : 

• Vous savez identifier les dependances entre classes. 

• Vous savez « casser » les cycles de dependances. 

• Vous savez appliquer le patron de conception Observer. 
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Objectifs 

■ Presenter les regies de generation de code Java a partir d'un modele UML 

■ Presenter les problemes du cycle reverse/generation 

■ Presenter les cycles de developpement avec UML 

D'UML a Java 

Nous avons compare au chapitre 3 la semantique UML avec la semanti que Java. Nous 
avons alors propose des regies de correspondance permettant de construire automatique- 
ment une partie d'un modele UM L a partir d'une application Java. Soulignons que ces 
regies represented une fagon parmi d'autres de passer dejava vers UML. E lies consti- 
tuent un des ponts semanti ques dejava vers UML. 

Dans le present chapitre, nous al Ions proposer un pont semanti que inverse, permettant de 
construire automatiquement une application Java a partir d'un modele UML. Ce pont 
permettra de real iser I 'operation de generation de code J ava a partir de model es UML. 

Pour etablir ce pont, nous devons definir un ensemble de regies de correspondances des 
concepts UML vers les concepts J ava. 

Regies de correspondance UML vers J ava 

1. A toute classe UM L doit correspondre une classe Java portant le meme nom que la 
classeUM L. 
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2. A toutei interface UM L doitcorrespondreune interface Java portantle meme nom que 
I 'interface UML. 

3. A toute propriete d'une classe UML doit correspondre un attri but appartenant a la 
classejava correspondant a la classe UML. Le nom de I 'attri but doit etre le meme 
que le nom de la propriete. Le type de I 'attri but doit etre une correspondancej ava du 
type de la propriete UM L. Si le nombre maximal de valeurs pouvant etre portees par 
la propriete est superieura 1, 1 'attri but J ava estun tableau. 

4. A toute operation d'une classe UM L doit correspondre une operation appartenant a la 
classejava correspondant a la classe UM L. Les noms des operations doi vent etre les 
memes. Etant donne que J ava ne supporte que les directions in et return, si I'opera- 
tion contient des parametres de direction out ou inout, nous considerons qu'il n'est 
pas possible de generer du code Java. Sinon, pour chaque parametre de I'operation 
UML dont la direction est in doit correspondre un parametre de I'operation Java. Les 
noms des parametres doi vent etre les memes. Les types des parametres doi vent etre 
une correspondance Java des types des parametres UML. Si I'operation UML 
contient un parametre de direction return, I'operation Java doit defini r un retourqui 
lui correspond. Si I'operation UML ne contient pas de parametre de direction return, 
I'operation J ava retourne void. 

5. Si une classe UM L A est associeea une classe UM L B et que I ' associati on soit navi- 
gable, il doit correspondre un attri but dans la classejava correspondant a la classe 
UM L A . Le nom de I ' attri but doit correspondre au nom du role de I 'association. Le 
type de I 'attri but doit etre une correspondancej ava de la classe UM L B associee. Si 
I'association specifie que le nombre maximal d'objets pouvant etre relies est supe- 
rieur a 1, I 'attri but Java est un tableau. Si I'association n'est pas navigable, nous 
consi derons qu'il n' est pas possi bl e de generer du code J ava. 

6. Si une classe UML herite d'une autre classe UM L, il doit correspondre une relation 
d' heritage (extends en Java) entre les classesjava correspondantes. Commejava ne 
supporte pas I 'heritage multiple, si une classe UM L herite de plusieurs autres classes 
UML, nous considerons qu'il n'est pas possible de generer du code J ava. 

7. Si uneclasseUML realise une ou plusieurs interfaces UM L, i I doitcorrespondreune 
relation de realisation entre la classe et les i nterf aces J ava correspondantes. 

8. Si une classe UML est contenue dans un package, la classe J ava correspondante doit 
declarer qu'elle appartient a un package J ava. Le nom du package Java doit etre le 
meme que le nom du package UML. 

9. Si un package UML importe un autre package UM L, toutes les classesjava corres- 
pondant aux classes UM L incluses dans le package UM L doivent declarer un import 
J ava vers toutes les classesjava correspondant aux classes incluses dans le package 
UML importe. 

Ces regies de correspondances ne prennent pas en compte les traitements associes aux 
operations UM L, car ceux-ci ne sont pas nativement defini s dans les model es. Le code 
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J ava genere ne contient done que des squelettes de code sans comportement reel associe 
aux methodes. Decefait, 1'application generee ne pourra jamais etre executee. 

Lorsque nous avons defini notre operation de Reverse Engineering, nous avons precise 
que le code des traitements associes aux operations eta it integre au modele a I'aide de 
notes UM L. Nous pouvons done aj outer la regie suivante a nos regies de generation de 
code, qui ne sera exploitable que si le modele contient des notes de code (ce qui est 
garanti si I e modele UM L est obtenu a parti r d'une operation de Reverse Engineering) : 

10. Si des notes de code J ava sont associees aux operations des classes U M L , ce code est 
recopiedans les operations J ava correspondantes. 

Notons que nos regies de correspondances ne beneficient pas assez de I'API Java. II 
serai t possible, par exemple, d'ameliorer la regie n° 5, qui portesur les associations entre 
classes, en remplagant I'uti lisation du tableau (qui est utilise pour les associations 
permettant de relier plusieurs objets) par eel le de la classej ava Array List, qui represente 
un tableau dynamique. 

Ainsi la regie n° 5 deviendrait : 

Si une classe U M L est associee a une autre classe U M L et que I'association soit navi- 
gable, il doit setrouver un attri but dans la classej ava correspondanta la classe UM L. 
Lenom del 'attri but doitcorrespondreau nom du role de I'association. Si I'association 
specifie que le nombre maximal d'objets pouvant etre relies est superieur a 1, le type 
de I 'attri but J ava est de type Array List. Sinon, le type de I 'attri but doit etre une corres- 
pondence J ava de la classe UML associee. Si I'association n'est pas navigable, nous 
considerons qu'il n'est pas possible de generer du codejava. 

Notons pour finir que ces regies de correspondances ne prennent pas en compte la 
semantique de contenance des associations, Java ne supportant pas un tel concept. Nous 
considerons done qu'il est impossible de generer du code Java si le modele UML 
contient des associations d'agregation ou de composition. 

En resume, les regies de correspondances que nous venons de presenter permettent de 
decrire brievement le fonctionnement d' une operation de generation de code J ava a parti r 
de model es UML. Contrairement aux regies de I 'operation de Reverse Engineering, ces 
regies contiennent des contraintes sur la nature des model es UM L a parti r desquels peut 
se faire la generation. Par exemple, il n'est pas possible de generer du codejava si des 
classes du modele U M L ont des heritages multiples ou si les operations du modele UML 
utilisent les directions out ou inout. 

De plus, I' operation de generation de codejava n'est pleinement exploitable que si el I e 
est executee sur un modele UML qui contient des notes de code associees a ses opera- 
tions (un modele obtenu a partir d'une operation de Reverse Engineering, par exemple). 
En effet, seule la regie n° 10 permet la generation de codejava executable. Lorsque 
I ' operation de generation de code est executee sur un modele qui n' a pas de notes de code 
associees a ses operations, I e code genere ne contient que des squelettes de code. 

Soulignons pour finir que I 'operation degeneration de code s'applique sur la partie struc- 
turelledu modele UM L au plus bas niveau d'abstraction. 
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La figure 5.1 represente cette operation selon notre representation du modele UM L. 



Figure 5.1 
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UML vers J ava et J ava vers UML 

Nous venons de voir deux operations qui permettent respectivement de passer de Java 
vers UML et de U M L vers J ava. 1 1 est des lors necessaire de savoir si les effets de ces 
deux operations s' annul ent. En d'autres termes, obtenons-nous le meme code apres avoir 
execute une operation de Reverse Engineering suivie d'une operation de generation de 
code? A I' inverse, obtenons-nous le meme modele apres avoir execute une operation de 
generation decode suivie d'une operation de Reverse Engineering ? 

En fait, telles que nous les avons definies, I'execution d'une generation de code suivie 
d'un Reverse Engineering peuvent retourner un modele different du modele a" entree, 
alors que I'execution d'un Reverse Engineering suivi d'une generation de code retour- 
nent toujours le meme code. 

La raison principale a cela est que I' operation de generation de code fait disparaitre les 
associations entre les classes UML dans I e code genere et que celles-ci ne reapparaissent 
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pas apres une operation de generation de code. De plus, la generation de code utilise des 
classes particulieres de I'API Java, qui apparaissent dans le modele apres I 'operation de 
Reverse Engineering. Par contre, tous les concepts Java sont integres dans le modele 
U M L et se retrouvent dans le code apres la generation de code. 



Personne 



nom : string 
tel[1..4]: string 
prenom[l..*]:string 



getNomO 



titula ire 



moyens de paiement compteCourant 



^> CompteBancaire 



Figure 5.2 

M odele U M L avant generation/reverse 



Parexemple, en executant I 'operation degeneration de code a parti rdu modele ill ustre a 
la figure 5.2, nous obtenons le code J ava suivant : 



public class Personne { 


public class CompteBancaire { 


ArrayList compteCourant ; 

} 


Personne titulaire ; 

} 



Apres I 'execution d'un Reverse Engineering, cecode permet d'obtenir le modele i 1 1 ustre 
a la figure 5.3, qui est completement different du modele d'origine. 



1 titulaire 



ArrayList 




Personne 




CompteBancaire 


< 


< 



compteCourant 1 

Figure 5.3 

M odele U M L apres generation/reverse 



Les effets engendres par les operations de generation de code et de Reverse Engineering 
sont dictes par les regies de correspondances qui definissent ces operations. Or, nous 
avons precise que ces regies de correspondances n'etaient en aucun cas standards et que 
chaqueoutil proposaitles siennes. Decefait, il est i mpossi bl e de predi re, sans connaitre 
tres precisement ces regies, quel sera le resultat obtenu apres des executions successives 
d' operations de generation de code et de Reverse Engineering. 

De plus, a I'heure actuelle, aucun outil du marche ne precise pleinement ses regies de 
correspondances. Nous deconseillons done, dans le cadre de ce cours, I'execution 
successive d' operations de Reverse Engineering et de generation de code, a moins de 
savoir exactement quels en seront les effets. 
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Approches UML etcode 

Nous venons de voir qu'il n'etait actuellement pas raisonnable d'executer successive- 
ment les operations de Reverse Engineering et de generation de code. Pour autant, ce 
sont ces operations qui permettent une synchronisation entre le code et le modele. 

Rappelons que notre objectif depuis le debut de ce cours est d'effectuer des operations 
sur les modeles (generer de la documentation, casser les dependances ou appliquer des 
patrons de conception) et d'effectuer des operations sur le code (coder les traitements 
associesaux operations, compiler et ex ecuter). 

II est done absolument necessaire de definir une approche permettant de realiser, d'une 
part, des operations sur le code et, d' autre part, des operations sur le modele, tout en 
gardant une synchronisation entre le code et le modele. 

Approches envisageables 

Approche Code Driven 

Le point de depart de cette approche est le code. L'objectif est de ne jamais utiliser 
I 'operation de generation de code. La coherence entre le modele et I e code est maintenue 
grace a I'operation de Reverse Engineering. L'interet de cette approche est I i mite, car 
seules les operations de lecture sur les modeles peuventetre uti I i sees. Par exemple, il est 
possiblede generer la documentation del 'application, mais il n' est pas possible de casser 
les dependances ou d'appliquer des patrons de conception sur les modeles. 

Approche M odel Driven 

Le point de depart de cette approche est le modele. L'objectif est de ne jamais utiliser 
I'operation de Reverse Engineering. La coherence entre le modele et le code est mainte- 
nue grace a I'operation de generation de code. L'interet de cette approche est actuelle- 
ment I i mite, car il n'est pas possible de modeliser en UM L les traitements associes aux 
operations. La generation de code executable n'est done pas possible. 

Soulignons cependant qu'il est possible de suivre une approche M odel Driven en inte- 
grant directement dans le modele U M L les notes de code J ava afin de pouvoir generer un 
code executable. Meme si cette approche consiste a integrer du Java dans le modele 
UML, el lereste une approche M odel Driven puisque I'operation de Reverse Engineering 
n'est jamais uti I i see. Son inconvenient est de devoir coder du Java dans le modele UM L 
(lesoutils UM L nesupportentquefaiblementcela actuellement). 

Approche Round Trip 

Le point de depart de cette approche peut etre soit le code, soit le modele. L'objectif est 
d' utiliser aussi bien les operations de Reverse Engineering que de generation de code 
pour assurer la synchronisation entre modele et code. Cependant, ces operations doivent 
etre bien preparees et ne doivent pas etre uti I i sees n'importe quand afin de ne pas subir 
les consequences des modifications qu'elles real isent. Cette approche est actuellement la 
plus interessante, car ellecumule les avantages offerts par UM L et par J ava. Cependant, 
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die est aussi la plus delicate a mettre en ceuvre, car die necessite une connaissance tres 
fine des operations de Reverse Engineering et degeneration decode. 

Dans le cadre de ce cours, nous utiliserons I'approche Round Trip avec les precautions 
suivantes : 

• Les moddes UM L nedoivent pas contenir d' heritages multiples entre classes. 

• Les moddes UML nedoi vent pas contenir d' associations non navi gables. 

• Les moddes U M L ne doivent pas contenir d' associations d'agregation ou de composition. 

• Les moddes UM L ne doivent pas contenir d'associations navigables sped fi ant que le 
nombre maximal d'objets pouvant etre relies est superieur a 1. A la place, nous ferons 
en sorteque les moddes UML utilisent la classe Array List. 

• L es modd es U M L doivent conteni r une note de code attachee a chaque operati on. 

Ces precautions nous permettront de real i ser successivement les operations de Reverse 
E ngineering et de generation de code tel les que nous les avons definies sans risquer de ne 
plus avoir de synchronisation entre lemoddeet I e code. 



Cycle de developpement UML 

Grace aux concepts que nous avons introduits jusqu'a present dans ce cours, nous pouvons 
definir un cycle de developpement UM L, dont les caracteri stiques sont les suivantes : 

• 1 1 suit une approche R ound Tri p, car i I uti I i se I es operati ons de generati on de code et de 
Reverse Engineering pour assurer la synchronisation entre le modde et le code. 

• II preconise la creation dedifferentsdiagrammesde classes afin demieux presenter la 
structuration de I'appl ication. Grace aux diagrammes de classes, il est possible de 
generer automatiquement une documentation de la structuration de I 'application a un 
bas niveau d' abstraction. 

• II preconise la suppression des cycles entre les packages grace a I 'identification des 
dependances entre classes et au mecanisme permettant de casser les cycles de depen- 
dances entre classes. 

• II preconise I 'application de patrons de conception surlemodde. 

• II contraint les modifications du modde UML afin que les executions successives de 
generation de code et de Reverse Engineering ne mettent pas en peril la synchronisa- 
tion entre modde et code. 

• II preconise de specifier les traitements associes aux operations des classes a I'aide de 
code Java. 

• II preconise de real i ser la compilation et I 'execution del 'application a I'aide des outi Is 
Java classiques. 

• II n'utilise que la partie structurelle au plus bas niveau d'abstraction du modde de 
I ' appl i cati on. 
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La figure 5.4 schematise ce cycle de developpement UML. 



Figure 5.4 
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Ce cycle de developpement UM L cumule done les avantages de la modelisation et de la 
programmation, tout en assurantune coherence globaledu modele etdu code. Grace a la 
modelisation, il facilite la generation de documentation, I 'identification de dependances, 
I a correcti on de cycl es de dependances et I ' appl i cati on de patrons de concepti on. G race a 
la programmation, il facilite le codage des traitements des operations, la compilation et 
I' execution. 



Synthese 

Ce chapitre a introduit I 'operation de generation de code Java a partir d'un modele 
UML. Cette operation est definie a I'aide de regies de correspondances entre les 
concepts UML et les concepts Java. 

Nous avons ensuite souligne que les operations de generation de code et de Reverse 
Engineering n'etaient pas symetriques. Les executions successives de ces deux 
operations peuvent engendrer de fortes modifications dans le modele et dans le code, qui 
ne vont pas sans consequences nefastes sur la synchronisation entre modele et code. 

Nous avons indique les differentes approches qui permettent d'utiliser UML dans un 
cycle de developpement. Nous avons explique I'approche Round Trip, preconisee 
dans le cadre de ce cours, qui utilise les operations de Reverse Engineering et de 
generation de code sous reserve de respecter certaines contraintes de modelisation afin 
d' assurer une synchronisation entre modele et code. 

Pour finir, nous avons schematise le socle fondateur de notre cycle de developpement avec 
U M L en precisant ses avantages et les differents points sur lesquels il apporte un gain. 
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Travaux diriges 

TD5. Generation de code 



Question 42 Ecrivez le code genere a partir de la classe Document illustree a la 
figure 5.5. 



Figure 5.5 

Classe Document 



Document 



id :integer 
titre:string 
etatinteger 



definirEtat() 



Question 43 Ecrivez le code genere a partir de la classe Bibiiotheque illustree a la 
figure 5.6. 



Figure 5.6 

Classes 
Bibiiotheque 
et Document 



Bibiiotheque 


doc 

> 


Document 




id:integer 
titrerstring 
etatinteger 


ajouterDocumentO 
lists rDocument() 


* 


definirEtat() 



Question 44 Ecrivez le code genere a partirdes classes Livre, CD, Revue (voir figure 5.7). 



Figure 5.7 

Classes CD, Livre 
et Revue 



Document 



id:integer 
titre:string 
etatinteger 



definirEtatO 

A - 



















CD 




Livre 




Revue 


CDDB:string 


ISBN rstring 


ISSN :string 
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Question 45 Ecrivez le code genere a partirde I'association CDdeLivre representee a la 
figure 5.8 apres avoir defini les regies de generation de code que vous 
comptez utiliser. 

Figure 5.8 

Association 
CDdeLivre 



CD 


cd CDdeLivre livre 


Livre 


CDDB:string 


ISBN:string 


* 0..1 







Question 46 Ecrivez le code genere a partir des classes representees a la figure 5.9 
apres avoir defini les regies de generation de code que vous comptez 
utiliser. 



Figure 5.9 

H eritage multiple 



Document 



id:integer 
titre:string 
etatinteger 



definirEtatf) 

Z\~~ 



Oeuvre 



TV 



CD 



CDDB:string 



Livre 



ISBN string 



U n mecanisme update permet de faire remonter les modifications du code 
Java dans le modele UML avec lequel il est deja synchronise. Par 
exemple, considerons que le modele UML et le code J ava de la classe 
Bibliotheque sont synchronises depuis la question 43 : si nous ajoutons 
dans le code I'attribut nom a la classe Bibliotheque, alors celui-ci apparaitra 
dans le modele UML apres execution de I'update. 

Nous considerons pour I'instantque le mecanisme d'update correspond a 
une operation de Reverse Engineering du code J ava, si ce n'est que les 
elements du code qui n'apparaissaient pas dans le modele y sont directe- 
mentajout.es. 

Question 47 Construisez le modele UML de la classe Bibliotheque (dont vous avez 
fourni le code a la question 43) obtenu par update apres avoir ajoute dans 
le code J ava les attributs nom, adresseet type dont les types sont des String. 

Question 48 Nous voulons maintenant, toujours dans le code Java, changer I'attribut 
type en attribut domaine. Pensez-vous qu'il soit possible, apres un update, 
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que les deux attribute type et domdine puissent etre presents dans le 
modele ? S i oui, a quoi est du ce comportement bizarre ? 

Question 49 Proposez un nouveau mecanisme d'update ne souffrant pas des defauts 
presentes a la question 48. 

Question 50 Proposez le mecanisme inverse de I'update permettant de modifier un 
modele UML deja synchronise avec du code et de mettre a jour automati- 
quement le code J ava. 

Question 51 Dans quelle approche de programmation par moderation (Model Driven, 
Code Driven et Round Trip) ces mecanismes d'update sont-ils 
fondamentaux ? 



Ce TD aura atteint son objectif pedagogique si et seulement si : 

• Vous comprenez le mecanisme de generation de code presente. 

• Vous avez pris conscience de la complexity et des limites d'une generation de 
code pour une application reelle. 

• Vous avez compris I'importance du mecanisme d'update. 
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Objectifs 

■ Presenter les concepts UML relatifs a la vue comportementale (diagramme de sequence) 

■ Presenter la notation graphique du diagramme de sequence UML 

■ Expliquer la semantique des sequences UML en precisant le lien avec les classes UML 



Vue comportementale du modele UML 

Depuis le debut de ce cours, nous n'avons presente que les concepts relatifs a la vue 
structurelle des applications. Dansle paradigmeorienteobjet, la structure d'une applica- 
tion est entierement defini e par ses classes et leurs relations. La vue structurelle est done 
completement couverte par les concepts UML relatifs aux classes (classe, operation, 
propriete, association, etc.). R appel ons que I e diagramme de classes est la representation 
graphique decette vue. 

L'aspect comportemental d'une application orientee objet est defini par la fagon dont 
interagissent les objets qui composent I ' appl i cati on. A I 'execution, I'objet est I'entite de 
base d'une application. Les objets qui composent une application pendant son execution 
et leurs echanges de messages permettent a I ' appl i cati on de real iser les traitements pour 
lesquel les el le a ete developpee. 

UML propose plusieurs vues permettant de defini r les interactions entre objets. Une de 
ces vues permet de presenter des exemples d'interaction entre plusieurs objets. Grace a 
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ces exemples d'i interactions, il est possible de mieux comprendre le comportement de 
I ' appl i cati on ou de verifier que T exempted' interaction sederouleconvenablement. 

Cette vue, dont la representation graphique est le diagramme de sequence, definit deux 
concepts principaux : celui d'objet et celui de message echange entre deux objets. Une 
interaction permet d' identifier plusieurs objets et de representor les messages qu'ils 
s'echangent. 

Concepts elementaires 

Cette section presente les concepts elementaires de la vue comportementale d'un model e 
UML. Dans notre contexte, ces concepts sont suffi sants pour exprimer des exemples 
d'execution d'une application. 

Objet 

Semantique 

Dans une application, chaque objet peut envoyer et recevoir des messages des autres 
objets qui composent I 'application. En UML, les objets qui parti ci pent a une interaction 
s'echangent des messages entre eux. 

Nous considererons que, dans une interaction, il n'existe pas d'objet qui n'echange pas 
de message avec d'autres objets. 

Dans une application, tout objet est au moins instance d'une classe concrete. Cette classe 
est eel I e qui a permisdeconstruirel'objet. En UM L, les objets qui parti ci pent a une inte- 
raction peuvent ne pas avoir de classe dont i Is sont instances. N ous appellerons ces objets 
des objets non types. Les objets non types sont utilises dans les interactions pour specifier 
des objets qui ne font que demander la realisation d' operations et dont on ne se soucie 
pasdeconnaitreletype. 

Dans une application, tout objet a un identifiant. En UM L, les objets qui parti ci pent a une 
interaction peuvent ne pas avoir d' identifiant. Nous appellerons ces objets des objets 
anonymes. Les objets anonymes sont utilises dans les interactions pour specifier des 
objets qui nesont utilises qu'une seulefois. II nesert alors a rien de bien les identifier. 

Graphique 

Les objets qui participent a une interaction sont represent.es graphiquement dans un 
di agramme de sequence par un carre contenant I ' i dentifiant de I ' obj et (si I ' obj et n' est pas 
anonyme), suivi du nom de la classe dont I'objet est instance (si I'objet est type). Attache 
a ce carre, une ligne verticale represente la vie de I'objet dans le temps (I'axe du temps 
etant dirige vers le bas du diagramme). 

La figure 6.1 represente quatre objets, dont un objet anonyme non type, un objet 
anonyme type, un objet identifie non typeetun objet identifies type. 

Dans le cadre de ce cours, nous preconisons d' identifier et de typer quasiment tous les 
objets de toutes les interactions. Cela permet un meilleur suivi des coherences entre les 
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Figure 6.1 

Representation 
graphique 
des objets 

dans les interactions 



idl: 



id2:B 



differentes parties du model e. En fait, nous utilisons les objets non types pour specifier 
les objets externes au systeme (comme les utilisateurs), dont nous ne connaissons pas le 
type. 

Message 

Semantique 

Dans une application orientee objet, les objets communiquent par echanges de messages. 
Le message I e plus important est le message de demande de realisation d' operation, par 
lequel un objet demande a un autre objet (ou a lui-meme) de real iser une des operations 
dont il est responsable. En theorie, avec ce message seul, il est possible de decrire 
completement le comportement d'une application. 

UM L integredonc I e message d'appel d'operation dans les interactions entre objets. Plus 
precisement, UML propose deux messages d'appel d'operation : un message pour les 
appels synchrones (I 'appelant attend de recevoir I e resultat de I 'operation avant de conti- 
nuer son activite) et un message pour les appels asynchrones (I 'appelant n'attend pas de 
recevoir le resultat de I'operation et continue son activite apres avoir envoye son 
message). 

UML propose aussi des messages de creation et de suppression d' objets afin de gerer le 
cycle de vie des objets participant a une interaction. Dans une interaction UML, les 
objets peuvent soit exister au debut de I' interaction, soit etre crees par d'autres objets 
pendant I' interaction. II est aussi possible de specifier des suppressions d' objets. Celles- 
ci sont initiees par des objets participant a I 'interaction. Un objet detruit ne peut plus 
recevoir de message. 

Graphique 

La figure 6.2 represente graphiquement les quatre messages suivants supportes dans les 
interactions UM L : 

• Le premier message est un message de creation echange entre I'objet identifie idi et 
l'objet identifie id2. Ce message signifie que I'objet idi cree I'objet id2. 

• Le deuxieme message est un message d'appel synchrone d'operation. L'objet idi 
demande a I'objet id2 de real iser I'operation nominee operationi. L'objet idi attend 
que l'objet id2 finisse de real iser cette operation avant de continuer son activite. Le 
message de fin detraitement est represente par unefleche pointillee. 
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• Le troisieme message est un message d'appel asynchrone d'operation. Ce message 
signifie que I'objet idl demande a I'objet id2 de realiser I'operation nommee 
operation2. line meme operation sur un meme objet peut etre appel ee de maniere 
synchrone et asynchrone dans une meme interaction. II aurait done ete possible 
d'appeler a nouveau I'operation operationi maisde maniere asynchrone. L'appel etant 
asynchrone, I'objet idi n'a pas besoin d'attendre la fin du traitement de I'operation 
pour continuer son activite. 

• Le dernier message est un message de suppression. L'objet idi suppri me I'objet id2. 



Figure 6.2 

Representation 
graphique 
des messages 
dans une interaction 



idl: 



creation 



operationi 



id2:B 



operation2 



suppression 



I 



Le temps dans les diagrammes de sequence 

Une interaction sped fie une succession d'echanges de messages entre les objets partici- 
pant a I'interaction. Le temps est done tres important puisqu'il precise I'ordre d'execu- 
tion entre tous les messages d'une meme interaction. 

Dans une interaction UM L, le temps est gouverne par deux regies principales (voir ci- 
apres). Ces regies considered les messages d'appel synchrone d'operation etde creation 
comme deux messages, un appel et un retour. II y a done une fleche de I'objet emetteur 
vers I'objet recepteur (appel) et une autre de I'objet recepteur vers I'objet emetteur 
(retour). 

Chaque message est ensuite decompose en deux evenements, un evenementd' envoi etun 
evenement correspondant a la reception. L'envoi est materialise par I'extremite de depart 
de la fleche correspondant au message et la reception par I'extremite d'arrivee de la 
fleche. A insi, I e temps est regule par les regies suivantes : 
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1. Sur I'axe d'un objet, tous les evenements sont ordonnes du haut vers le bas. Cela 
entrame qu'un evenement arrive avant un autre evenement s'il est positionne plus 
haut sur I'axe d'un meme objet. 

2. Pourun meme message, I'envoi sederouletoujours avant la reception. 

Grace a ces deux regies, il est possible de definir un ordre parti el entre tous les evene- 
ments d'une interaction UML. 

La figure 6.3 presente une interaction entre trois objets qui s'echangent des messages 
d'appels synchrones et asynchrones d'operations. 



Figure 6.3 

Diagramme 
de sequence 
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id2:B 



ml 
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m3 
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Grace a nosdeux regies, nous savons que ces echanges obeissenta I 'ordre suivant : 
Grace a la regie 1 : 

1. Sur I'axe de I 'objet idi : mi (appel/envoi) avant mi (retour/reception ) avant m3 (appel/ 
envoi) avant m3 (retour/reception) avant m4 (appel/envoi) avant m6 (appel/envoi). 

2. Sur I'axe de I'objet id2 : mi (appel/reception) avant m2 (appel/envoi) avant m2 (retour/ 
reception) avant mi (retour/envoi) avant m4 (appel/reception) avant m5 (appel/envoi). 

3. Sur I'axe de I'objet id3 : m2 (appel/reception) avant m2 (retour/envoi) avant m3 (appel/ 
reception) avant m3 (retour/envoi) avant m5 (appel/reception) avant m6 (appel/recep- 
tion). 
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Grace a la regie 2 : 

4. Pourtous les messages mi (x/envoi) avantmi (x/reception). 

Grace a ces deductions, nous pouvons voir, par exemple, qu'il n'existe pas d'ordre entre 
m5 (appel/envoi) et m6 (appel/envoi). Cela signifie que I'interaction ne precise pas que 
I'envoi del'appel asynchrone del' operati on msse fait avantl' envoi del'appel asynchrone 
de I' operation m6, meme si le diagramme semble indiquer le contraire. N otons cependant 
que la reception de I'appel asynchrone de I' operation m5 se fait avant la reception de 
I'appel asynchrone de I' operation m6. 



Liens avec la vue structurelle du modele 

Nous avons insiste fortement dans les premiers chapitres de ce cours sur les relations de 
coherence qui existent entre les differentes parties d'un meme modele. 

Nous avons pour I'instant presente les vues structurelle et comportementale d'un modele 
U M L . Nous precisons dans cette section les regies de coherence entre ces deux vues. 



Objetetclasse 

Les seules relations de coherence que nous considerons entre les diagrammes de 
sequence et les diagrammes de classes dans I e cadre de ce cours sont les suivantes : 

• Tout objet participant a une interaction doit obligatoirement avoir son type decrit sous 
forme de classe dans la parti e structurelle. Nous deconseillons fortement I 'utilisation 
d'objets non types. 

• Tout message d'appel d'operation (synchroneou asynchrone) doitcibler uneoperation 
specifiee dans la vue structurelle. Cette operation doit appartenir a la classe dont 
I ' obj et qui recoit I e message est i nstance. 

• Tout message d'appel d'operation (synchrone ou asynchrone) doit porter les valeurs 
des parametres de I 'operation ciblee par le message. 

Considerons, par exemple, I'interaction representee par I e diagramme del a figure 6. 4. 



Figure 6.4 

Objets types 

dans une interaction 



idl:A 



id2:B 



operation(123,"texte") 



i 
i 



Les regies de coherence entre parties de modeles nous imposent d'avoir dans la partie 
structurelle la definition des classes a et b ainsi que la definition de I 'operation operationi 
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contenuedanslaclasseB. Notons que I 'operation operationi possede deux parametresde 
direction in et dont les types sont respectivement integer et string 

La figure 6.5 represente le diagramme de classes correspondant a cette parti e structurelle 
(les parametres de I'operation de la classe b sont masques). 



Figure 6.5 

Classes des objets 
types 



operationf) 



Les regies de coherence que nous venons de presenter imposent des contraintes sur la 
parti e comportementale du model e ainsi que sur la parti e structurelle. Pour autant, el les 
n' imposent aucune contrainte sur la fagon de creer un model e coherent. 

II est done parfaitement envisageable de commencer la construction d'un model e cohe- 
rent par la parti e comportementale puis de finir par creer une parti e structurelle cohe- 
rente. Inversement, il est aussi possible de commencer par la parti e structurelle puis de 
finir par la partie comportementale. La troisieme approche possible est de construire en 
parallele les parties comportementale et structurelle. Nous conseillons fortement de 
tester chacune de ces trois approches afin de trouver celle qui convient le mieux a sa 
propre facon depenser. 



Diagramme et modele 

Nous avons vu au chapitre 3 la difference entre diagramme UML et modele UML. 
Rappelons qu'un diagramme est une representation graphique d'un modele et qu'a un 
modele peuvent correspondre plusieurs diagrammes. Cette relation que nous avons illus- 
treesur la partie structurelle du modele est tout aussi importantepour la partie comporte- 
mentale du modele. 

Un diagramme de sequence est la representation graphique de la partie comportementale 
(interaction) d'un modele UML. Toute les informations (objets, messages, etc.) sont 
contenues dans le modele et representees graphiquement a I 'aide des diagrammes. II est 
done possible de representer une meme information dans differents diagrammes. 

En fait, seuls les objets sont represents dans plusieurs diagrammes. Cela permet de 
representer graphiquement I e fait qu'un meme objet parti cipe a plusieurs interactions. 
L'objectif est de representer differentes possibility d'un meme comportement. Nous 
conseillons, par exemple, de specifier les comportements nominaux (normal et sans 
erreur) et les comportements soulevant des erreurs avec les memes objets. 

L'exemple il lustre a la figure 6.6 presentedeux interactions qui peuvent s' ex ecuter dans 
une application de gestion de prets bancaires. Ces interactions font intervenir les memes 
objets (le client ci et la banque bk). N otons que nous avons specifie le client avec un objet 
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non type. La premiere interaction represente un cas nominal : le pret est accorde. La 
deuxieme montre un cas soulevant une erreur : I e pret est refuse. 



Figure 6.6 

Deux diagrammes 
partageant 
de memes objets 



client: 



demande preUOOO) 



acceptation 



bk:Banque 



creation 



pl:Pret 



client: 



demande pret(1000) 



bk:Banque 



refus 



Le fait qu'un objet appartienne a plusieurs interactions n'a pas de consequence sur 
I'ordre entre les evenements des interactions. II existe un ordre pour chaque interaction, 
et ces ordres sont independant les uns des autres. 



Concepts avarices 

Les concepts avances que nous presentons dans cette section permettent de bien 
comprendre le role des interactions dans un modele UM L vis-a-vis de la generation du 
code. Les concepts ajoutes dans la version UML 2.1 renforcent d'ailleurs ce role. 



Interactions et generation de code 

M erne si nous avons deja indique que les interactions permettaient uniquement de speci- 
fier des ex emplesd' execution a" application, il estimportantdemontrer pourquoi ellesne 
peuvent etre uti I i sees pour specifier integralement des algorithmes et ainsi servir a la 
generation decode. 

II est important de preciser qu' une interaction ne defi nitqu' une seule execution possible, 
alors qu'un algorithme defi nit I'ensemble des executions possibles. Pour specifier un 
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algorithme a I'aide d' interactions, il faudrait pouvoir specifier chacune des executions 
possibles sous la forme d'une interaction. II faudrait done que I 'ensemble des executions 
possibles soit fini mais aussi que les resultats retournes par I'algorithme ne dependent 
que des valeurs donnees en entree (determinisme) et que I'algorithme ne modifie pas les 
etats des objets participant a sa realisation. 

Prenons, parexemple, I'algorithme correspondanta la porte logique ET real isant I 'opera- 
tion booleenneET. Celui-ci semble pouvoir etre specifie integralement a I 'aided' interac- 
tions puisque I 'ensemble des executions possibles est fini, que le resultat ne depend que 
de I 'entree et que I'etat de I'objet ne change pas apres execution de I'algorithme. 

Les quatre executions possibles de I'algorithme semblent pouvoir etre representees de la 
maniere illustree a la figure 6.7. 



utilisateur: 



I 

I 

I 
I 
I 

I 
I 



add(true,true) 



true 



el:PorteET 



utilisateur: 



add(true,false) 



false 
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utilisateur: 



I 

I 

I 
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add(false,false) 



false 



el:PorteET 



utilisateur: 



add(false,true) 



false 



I 
I 

Figure 6.7 

Diagrammes de sequence specifiant I'algorithme de la porte logique ET 



el:PorteET 



Pour pouvoir etre totalement sur que ces interactions specifient I'integralite des executions 
dela porte ET, il fautsavoir, d'une part, que la porte ET a un comportement deterministe(le 
resultat ne depend que del 'entree) et, d'autrepart, que I 'execution dela porte ET ne modi- 
fie par I'etat de I'objet. En effet, si la porte ET avait un comportement indeterministe ou si 
le comportement modifiait I'etat de I'objet, il ne serait pas possible de generer le code. 
M alheureusement, il n'est pas possible de preciser ces informations en U M L . 

En posant toutes ces conditions (ensemble fini d'executions, determinisme et pas de 
modification de I'etat de I'objet), il serait possible de generer lecodesuivanta partir des 
diagrammes que nous venons de presenter : 
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public boolean addtboolean a , boolean b) { 
if (a && b) return true ; 
else if (a && !b) return false ; 
else if ( !a && !b) return false ; 
else if ( !a && b) return false ; 

} 

En conclusion, nous pouvons dire qu'il est possible de specifier des algorithmes et de 
generer du code a parti r d' interactions si I 'ensemble des comportements possibles est 
fini, si lecomportementspecifieestdeterministeetsi lecomportementnemodifiepas les 
etats des objets. En d'autres termes, eel a n'est pas impossible mais reste suffisamment 
rare pour ne jamais etre employe. 

Fragment d'interaction 

Dans UML 1.4 et les versions precedentes, il n'etait pas possible de composer des inte- 
ractions entre elles, ni d'integrer une interaction dans une autre interaction. Cela posait 
probleme parce qu'il n'etait pas possible de specifier et de reutiliser des interactions afin 
d'en construirede plus complexes. 

Ce probleme a ete completement resolu avec UML 2.1, qui supporte le concept de frag- 
ment d'interaction. Un fragment permet d'identifier une sous-partie d'une interaction 
afin que celle-ci soit reference© par d'autres interactions. Associe au concept d'interac- 
tion, UML 2.1 propose des operateurs permettantde specifier des conditions d'execution 
telles que les boucles (loop) ou les tests (if then else) sur les fragments d' interactions. 

Grace a ces nouveaux concepts, il est possible de specifier des exemples d'execution 
beaucoup plus complexes et beaucoup plus lisibles grace a la possibilite de decomposer 
les interactions en sous-interactions. Cependant, dans le contexte de ce cours, nous 
n'utilisons pas ces concepts avances, car nous n'en avons pas besoin pour presenter les 
avantages qu'apportent les interactions lorsque nous utilisons UML pour le developpe- 
mentd'applications. 

Limites intrinseques des interactions 

Les interactions permettent uniquement de presenter des echanges de messages entre 
objets. II n'est done pas possible de specifier : 

• Les acces aux propriet.es des objets, a moins d'utiliser des operations d'acces aux 
propriet.es. 

• Les navigations sur les associations navi gables. 

• Les creations de liens entre objets. 

• Lesappelsaux operations de classes, caraucun objet n'est directementresponsablede 
la realisation de I'operation. 
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Synthese 

Nous avons montre dans ce chapitre comment la vue comportementale pouvait etre 
model i see en UM L a I'aide du concept d' interaction. Une interaction UM L permet de 
specifier un exemple d'execution d'une application. Plus precisement, une interaction 
specifie les echanges de messages effectues entre plusieurs objets qui composent 
I' application. 

Apres avoir presente les concepts de base des interactions (objet et message), nous 
avons specifie les contraintes de coherence qui existent entre la parti e structurelle et la 
partie comportementale du modele. Nous avons aussi presente les differentes 
approchesde construction permettantla realisation d'un modele coherent. 

Nous avons en outre montre pourquoi les interactions ne permettaient pas de specifier 
des algorithmes et ne permettaient done pas de generer du code. Nous avons en 
particulier insiste sur le fait qu'une interaction ne specifiait qu'une seule execution 
possible d'une application. 

Pourfinir, nous avons introduit les concepts avances des interactions UM L en presentant 
notamment le concept de fragment, qui a ete defini dans la version 2.0 d'UML. 
Soulignons que nous n'utiliserons pas ces concepts dans la suite de notre cours. 



Travaux d i r iges 

TD6. Diagrammes de sequence UML 



Lapplication ChampionnatEchecs, qui devra permettre de gerer le deroulement d'un cham- 
pionnat d'echecs est actuellement en cours de developpement. L'equipe de developpe- 
ment n'a pour I'instant realise qu'un diagramme de classes de cette application (voir 
figure 6.8). 

La classe ChampionnatDEchecs represente un championnat d'echecs. Un championnat se 
deroule entre plusieurs joueurs (voir classe Joueur) et se joue en plusieurs parties (voir 
classe Partie). La propriete MAX de la classe ChampionnatDEchecs correspond au nombre 
maximal de joueurs que le championnat peut comporter. La propriete fermer permet de 
savoir si le championnat est ferme ou si de nouveaux joueurs peuvent s'inscrire. 

ChampionnatDEchecs possede les operations suivantes : 

• inscriptionJoueur(in nomrstring, in prenom:string) : integer permettant 
d'inscrire un nouveau joueur dans le championnat si le nombre de joueurs inscrits 
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n'est pas deja egal a max et si le championnat n'est pas deja ferme. Si I'inscription 
est autorisee, cette operation cree le joueur et retourne son numero dans le cham- 
pionnat. 

genererPartie( ) : permet de termer le championnat et de generer toutes les 
parties necessaires. 

obtenirPartieDUnJoueurO'n numero :integer) : Partie[*] : permet d'obtenir la liste 
de toutes les parties d'un joueur (dont le numero est passe en parametre). 

calculerClassementDUnJoueurO'n numero :interger): integer permettant de 
calculer le classement d'un joueur (dont le numero est passe en parametre) 
pendant le championnat. 



Figure 6.8 

Classes 
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La classe Partie represente une des parties du championnat. La classe Partie est 
d'ailleurs associee avec la classe ChampionnatDEchecs, et I'association precise qu'un cham- 
pionnat peut contenir plusieurs parties. Une partie se joue entre deux joueurs. Un joueur 
possede les pieces blanches et commence la partie alors que I'autre joueur possede les 
pieces noires. Les associations entre les classes Partie et Joueurs precisent cela. La 
propriete numero correspond au numero de la partie (celui-ci doit etre unique). La propriete 
fini permet de savoir si la partie a deja ete jouee ou pas. 

La classe Partie possede les operations suivantes : 

• jouerCouptin coup:string) : permet de jouer un coup tant que la partie n'est pas 
finie. Le traitement associe a cette operation fait appel a I'operation verifierMat 
afin de savoir si le coup joue ne met pas fin a la partie. Si tel est le cas, I'operation 
finirPartie est appelee. 

• verifierMat( ) : boolean permettant de verifier si la position n'est pas mat. 

• finirPartie : permet de preciser que la partie est finie. II n'est done plus possible 
de jouer de nouveaux coups. 
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La classe Joueur represente les joueurs du championnat. La classe Joueur est d'ailleurs 
associee avec la classe ChampionnatDEchecs, et I'association precise qu'un championnat 
peut contenir plusieurs joueurs. La propriete numero correspond au numero du joueur 
(celui-ci doit etre unique). Les proprietes nom et prenom permettent de preciser le nom et le 
prenom du joueur. 

Un championnat d'echecs se deroule comme suit : 

• Un administrateur de I'application cree un championnat avec une valeur MAX. 

• Les participants peuvent s'inscrire comme joueurs dans le championnat. 

• L'administrateur cree I'ensemble des parties. 

• Les participants, une fois inscrits, peuvent consulter leur liste de parties. 

• Les participants, une fois inscrits, peuvent jouer leurs parties. Nous ne nous inte- 
ressons qu'aux coups joues par chacun des deux joueurs. Nous ignorons I'initiali- 
sation de la partie (identification du joueur qui a les pions blancs et done qui 
commence la partie). 

• Les participants peuvent consulter leur classement. 

Dans les questions suivantes, nous allons specifier des exemples d'execution de Cham- 
pionnatDEchecs avec des diagrammes de sequence. 

Question 52 Comment modeliser les administrateurs et les participants ? 

Question 53 Representez par un diagramme de sequence le scenario d'execution 
correspondant a la creation d'un championnat et a I'inscription de deux 
joueurs. Vous assurerez la coherence de votre diagramme avec le 
diagramme de classes fourni a la figure 6.8. 

Question 54 Representez par un diagramme de sequence le scenario d'execution 
correspondanta la creation de I'ensemble des parties pourle championnat 
cree a la question 53. Vous assurerez la coherence de votre diagramme 
avec le diagramme de classes fourni a la figure 6.8. 

Question 55 Representez par un diagramme de sequence le scenario d'execution 
correspondant au deroulement de la partie d'echecs entre deux joueurs. 
Vous pouvez considerer une partie qui se termine en quatre coups. Vous 
assurerez la coherence de votre diagramme avec le diagramme de 
classes fourni a la figure 6.8.. 

Question 56 Est-il possible de generer automatiquement le code d'une operation de 
cette application a partirde plusieurs diagrammes de sequence ? 

Question 57 Est-il possible de construire des diagrammes de sequence a partirdu code 
d'une application ? 

Une equipe de developpement souhaite realiser une application Calculus 
qui permet a des utilisateurs d'effectuer des operations arithmetiques 
simples sur des entiers : addition, soustraction, produit, division. Cette 
application a aussi une fonction memoire qui permet a I'utilisateur de 
stacker un nombre entier qu'il pourra ensuite utiliser pour n'importe quelle 
operation. Les operations peuvent directement s'effectuer sur la memoire. 
L'utilisateur se connecte et ouvre ainsi une nouvelle session. P uis, dans le 
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cadre d'une session, I'utilisateur peut demander au systeme d'effectuer 
une suite d'operations. 

Question 58 Utilisez des diagrammes de sequences pour representer les differents 
scenarios d'execution du service Calculus. 

Question 59 Pour chacune des instances apparaissant dans votre diagramme de 
classes, creez la classe correspondante. 

Ce TD aura atteint son objectif pedagogique si et seulement si : 

• Vous savez elaborer un diagramme de sequence coherent avec un diagramme de 
classes. 

• Vous savez elaborer un diagramme de classes coherent avec un ensemble de 
diagrammes de sequence. 

• Vous avez compris la relation qui existe entre une interaction et du code. 
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Objectifs 

■ Presenter les concepts du test 

■ Sensibiliser a la difficulty de la construction d'une suite de tests 

■ Presenter I'interet des interactions UML pour la specification des cas de test 

■ Presenter le cycle de developpement avec UML integrant les tests 



Les tests 

Grace notamment aux techniques dites XP (extreme Programming), les tests sont de 
plus en plus utilises en developpement. L'idee general e est de pouvoir tester le code que 
nous sommes en train de developper afin de nous assurer que celui-ci est correct, c'est-a- 
direqu'il respecte lefameux besoin du client (voir le chapitre 1). 

Le concept de test n'est cependant pas si simple, et il est necessaire de bien avoir en rite 
certaines definitions avant devoir comment integrer les tests dans un cycle de developpe- 
ment avec UML. 

Avant de presenter les definitions des concepts necessaires aux tests, il est important de 
savoir repondre a la question suivante : « A quoi sert le test? ». Pour NEEE, le but du 
test est de reveler les fautes. 
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II s'ensuit les definitions suivantes : 

• Unefauteintervientquand I' execution d'un logiciel fournitun resultat autre que eel ui 
attendu (IEEE std 982 1044). 

• U ne faute est causee par une ou pi usi eurs defai I lances dans une i implementation (IEEE 
std 982 1044). 

• Un cas de test est un test d'une propriete particul i ere d'une application. II s'agit d'un 
scenario d' execution de I'application exhibant une suite de stimuli et comparant les 
resultats obtenus apres stimulation de I'application avec les resultats attendus. 

• Une suite detests est un ensemble de cas detest permettant de valider I'ensembledes 
proprietes d'une application. 

En resume, nous pouvons dire que les tests sont realises dans I'objectif de trouver les 
defai I lances (bogues) d'une application. Pour ce faire, chaque test (cas de test) stimule 
I'application afin de provoquer une eventuelle faute. Lorsqu'une faute est revelee, cela 
signifie que I'application contient une ou pi usi eurs defai I lances. 

L' idee principale du test fonctionne done sur I' implication suivante : 

Faute revelee implique defaillance(s) dans I'application. 

A parti r de cette implication, nous comprenons mieux pourquoi letestapourobjectif de 
reveler desfautes : c' est en revel ant des fautes que nous pouvons affirmer que I'applica- 
tion contient des defai I lances. 

Soulignons que cette implication n'est pas une equivalence. Ce n'est pas parce 
qu'aucune faute n'est revelee que nous pouvons affirmer que I'application ne contient 
pas de defai I lances. 

Soulignons de surcrott que les tests n'offrent aucun mecanisme pour trouver la raison des 
defai Nances dans le code de I'application et, parvoiede consequence, aucun mecanisme 
pour lescorriger. 

Associes a ces concepts relativement theoriques, les concepts suivants ont ete definis afin 
de mettre en pratique I 'execution du test : 

• U n cas de test abstrait est un cas de test construit a parti r de la specification de I'appli- 
cation. 

• Un cas de test executable est un cas de test executable sur une architecture d'imple- 
mentation cible. Un test executable est construit a parti r d'un test abstrait. 

• Un testeur est une application qui control e I 'execution de I'application a tester en lui 
fournissant les entrees et en comparant les resultats retournes par I'application aux 
resultats prevus (e'est-a-dire les resultats specifies). 

Ainsi, afin derealiser etd'executer une suite detests sur une application, il est necessaire 
de: 

1. Construi re I 'ensemble des cas de test abstraits composant la suite de tests. Ces cas de 
test sont bases sur la specification de I'application. 
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2. Construirel'ensembledescasdetestexecutablescomposantla suite detests. Cescas 
detest sont bases sur les cas detest abstraits et doivent pouvoir s'executer sur I' appli- 
cation. 

3. Construire un testeur capable d'executer la suite de tests sur I'application afin de 
rendre le verdict (comparaison entre les resultats obtenus et les resultats attendus). 
Nous verrons dans la suite de ce chapitre que certains environnements Open Source 
proposent des testeurs. 



Comment utiliser les tests ? 

Les definitions que nous venons de rappeler impliquentqu'il faut disposer d'une specifi- 
cation de I'application pour pouvoir construire les cas de test abstraits. Dans notre 
contexte, nous pouvons considerer que la specification de I'application est incluse dans le 
modele de I'application. 

Nous avons aussi montre qu'il fall ait disposer d'une application executable pour cons- 
truire des cas de test executables. Dans notre contexte, nous pouvons reduire I'applica- 
tion executable au code de I'application, car seul le code est necessaire pour pouvoir 
executer I'application. 

Cette distinction entre « specification de ['application » et « application executable » 
ainsi que les relations qui existent avec les cas de test abstraits et executables sont sche- 
matisees a la figure 7.1 (les fleches represented les dependances entre les elements). 



Figure 7.1 

Dependances 
entre tests 
et application 



Specification de 
I'application 



Application 
executable 



Cas de test 
abstrait 



Cas de test 
executable 



Cette presentation des relations entre, d'une part, les cas de test abstraits et executables 
et, d'autre part, la specification de I'application et I'application executable met bien en 
evidence I' importance des cas de test abstraits. 

En effet, c'est uniquement de leur qualite que depend la qualite des resultats obtenus (en 
terme de fautes revelees, par exemple). Si les cas de test abstraits sont mal construits et 
stimulent mal I ' appl i cation, aucune faute ne peut etre revel ee. L es cas de test executables 
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ne sont qu'un reflet des cas detest abstraits afin de permettre leur execution sur I' applica- 
tion. 

De ce fait, la difficulte la plus importante dans la realisation d'une suite de tests reside 
dans la construction des cas detest abstraits. Comment construirede « bons » cas detest 
abstraits, autrement dit comment construire des cas de test qui permettent de reveler les 
fautes d'une application ? Ces questions rel event encore malheureusement du domaine 
de la recherche. 

Nous pourrions ajouter la question suivante : comment faire un ensemble de cas de test 
abstraits complet, autrement dit comment faire un ensemble de cas de test suffisamment 
exhaustif pour assurer une certaine qualite d'une application lorsque aucune faute n'est 
revel ee ? Ces questions, tout aussi importantes que les precedentes, sont aussi des ques- 
tions de recherche. 

Nous ne detail Ions pas les responses actuelles a ces questions, qui sortent du contexte de 
ce cours. Nous pouvons neanmoins prendre conscience de leur complexity grace a un 
ex emple simple tel quecelui d'une application realisant un tri alphabet] que sur les cases 
d'un tableau de chaines de caracteres. 

U ne faute possible de cette appl i cation serai t de mal trier les cases du tableau. Construire 
un cas de test visant a reveler cette faute est cependant extremement complexe. Sur quel- 

I es chat nes de caracteres faut-i I tester I ' appl i cati on ? Sur quel I es tai 1 1 es de tabl eau faut-i I 
tester I ' appl i cati on ? Quel serait un ensemble de cas de test abstraits suffisamment 
complet pour pouvoir assurer dans une certaine mesure que I ' appl i cati on realise correc- 
tementletri de n'importe quel tableau? 

Ecriture de cas de test a partir d'un modele UML 

Le test apporte un gain significatif dans le developpement d'applications informatiques. 

II est done absolument necessaire de I'integrer a notre cycle de developpement avec 
UML. Nous presentons dans cette section une facon de specifier les cas de test avec 
UML. 



Cas de test abstrait et interaction 

Nous avons vu au chapitre precedent qu'une interaction representait une succession 
d'echanges de messages entre plusieurs objets qui peuvent survenir pendant I 'execution 
d'une application. 

II est possiblede verifier qu'une interaction est real i see par I 'execution d'une application. 
Cela signifie que la succession d'echanges de messages specifiee par I'interaction a ete 
real i see par I ' appl i cation lorsdeson execution. 

Dans I e contexte du test, nous pouvons tres facilement faire un rapprochement entre les 
interactions et les cas detest. En effet, il est possible de considerer que la parti e du cas de 
test qui concerne les stimuli envoyes par le testeur vers I 'application est un echange de 
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messages entre le testeur et des objets de I ' appl icati on. Cette partie du cas de test peut 
done etre specifiee grace a une interaction. 

Pour pouvoir specifier integralement un cas de test, il faut des lors etre capable d'ajouter 
aux interactions la specification des resultats attendus, ainsi qu'une information precisant 
quel'interaction specifie un scenario i nitie par un objet externe a I' application (le testeur). 

Nous proposons done de modifier I esclassiques interactions UM L afin de pouvoir speci- 
fier des cas de test. Nous appellerons interaction de test une interaction respectant les 
contraintes suivantes : 

• L'interaction doit obligatoirement contenir un objet representant le testeur. Cet objet 
doit etre identifie Testeur et ne pas avoir de type. L'objet Testeur ne doit pas etre cree 
ni supprime par un objet de l'interaction. L'objet Testeur nedoit pas non plus recevoir 
de message d'appel d'operation. 

• L'interaction doit obligatoirement contenir d'autres objets. Tous les autres objets 
doivent etre identifies et types. Tous ces objets doivent etre crees par l'objet Testeur. 

• L'interaction peut contenir des messages d'appel d'operation synchrone ou asyn- 
chrone, maisseul l'objet Testeur peut etre l'objet qui envoie ces messages. 

• L'interaction doit contenir une note contenantleresultatattendu. 

Nous appellerons diagramme de sequence de test le diagramme de sequence representant 
graphiquement une interaction detest. Ce diagramme doit respecter les contraintes suivantes : 

• L'objet Testeur doit etre l'objet le plus a gauche du diagramme. 

• La note contenantleresultatattendu doit apparaitre sur lediagramme, de preference en 
bas, apres I e dernier message. 

La figure 7.2 presente un diagramme de sequence de test representant un cas de test 
abstrait sur I'algorithme de tri que nous avons presente precedemment. Ce diagramme 
respecte toutes les contraintes que nous avons definies. Soulignons que ce cas de test 
abstrait ne permet que de s' assurer que I'algorithme ne retourne pas d'erreur de tri si 
nous lui demandons de trier le tableau « b », « a », « c ». Ce cas de test ne donne done 
aucune garantie quant au resultat du tri sur tout autre jeu de donnees. 

Soulignons que les interactions detest permettent de specifier les cas detest abstraits et 
non les cas de test concrets. En effet les interactions sont coherentes avec les classes 
UM L qui ne sont pas executables car el les ne contiennent pas les traitements associes a 
leurs operations autrement que sous forme de note de code ecrite dans des langages de 
programmation tels que J ava. 

Cas de test executables et interactions 

Nous avons deja precise qu'un cas de test executable eta it le reflet d'un cas de test 
abstrait afin de permettre son execution sur I ' appl i cati on. Dit autrement, un cas de test 
executable est la traduction d'un cas de test abstrait dans un langage de programmation 
parti culier. 
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Figure 7.2 

C as de test abstrait 
en UML 



Testeur 



creation 



t1 :Tri 



trier("b","a","c") 



resultat attendu 
"a", " b", "c" 



Etant donne, d'une part, que nous specifions les cas de test abstraits a I'aide d'interac- 
tions coherentes avec la parti e structurelle du modeleetque, d' autre part, nous generons 
le code de I 'application grace a I' operation degeneration decode a parti r decette parti e 
structurelle, il semble naturel de vouloir generer les cas detest ex ecutables a I'aide d'une 
operation degeneration decode detest si mi I aire a I 'operation degeneration decode que 
nous avons presentee au chapitre 5. 

Nous proposons done de definir une operation de generation de code de test a partir 
d' une i nteraction. Ce code de test devant etre execute par un testeur, nous faisons I e choix 
de ne pas developper nous-meme ce testeur mais de reutil iser le framework de test J U nit 
(http://www.junit.org/index.htm). Celui-ci propose une A PI J ava permettant de coder des cas de 
test et de les executer sur une application J ava. 

Notre operation degeneration decode detest a partir d'une interaction s'appuiedonc sur 
le framework J U nit et est specifiee avec les regies de correspondance suivantes : 

1. A toute interaction doit correspondre un cas de test JUnit. Cela signifie qu'une 
nouvelle classejava doit etre construite. Cette classe doit heriter de la classeJUnit 
Testcase. La classe doit contenir une methode correspondant au test. Cette methode 

aura pour nom testExecutable. 

2. Dans la methode testExecutable de la classe correspondant au cas de test, il doit 
correspondre un appel de methode J ava pour chaque message de I' interaction partant 

de I'objet Testeur. 

- Si le message est une creation, I'appel de methode J ava doit etre une creation d'objet 

(new). 

- Si le message est une suppression d'objet, nous considerons que la generation 
s'arreteen soul evant une erreur, car J ava ne supporte pas les suppressions d'objets. 
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- Si le message est un appel synchrone d' operation, I'appel demethodejavadoitetre 
un appel vers la methodejava correspondant a I'operation. 

- Si le message est un appel asynchrone d'operation, nous considerons que la gene- 
ration s'arrete en soulevant une erreur, car Java ne supporte pas nativement les 
appels asynchrones. 

3. Dans la methode testExecutabie de la classe correspondant au cas de test, il doit 
correspondre une assertion J Unit correspondant au resultat attendu specifie dans 
I'interaction. Pour pouvoir automatiser I'ecriture de cette assertion J Unit, il faut 
proposer un formalisme de specification du resultat attendu dans I'interaction UM L 
(notre exemple ne fait que specifier le resultat attendu en langage naturel). UM L ne 
standardise pas un tel formalisme, mais la plupart des outils UM L proposent chacun 
leur propre formal ismede specification. 

En appli quant ces regies de generation de code de test sur le cas de test abstrait que nous 
avons specifie a la section precedente a I'aide d' une interaction, nous obtenons le cas de 
test executable suivant: 

public class Tri Interaction extends TestCase { 
public void testExecutabl e( ) { 
tl = new Tri ( ) ; 

String[] resul tatObtenu = tl.trierC'b" , "a", "c") ; 

assertEqual s( resul tatObtenu[0] , "a") ; 
assertEqual s( resul tatObtenu[l] , "b") ; 
assertEqual s( resul tat0btenu[2] , "c") ; 
} 

} 

Grace au framework J Unit, ce cas de test executable peut etre execute sur I 'appli cation 
qui aura eteobtenuea I'aide d'une generation decode. 
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Figure 7.3 

Le test dans notre cycle de developpement avec UML 

Nous avons introduit dans ce chapitre les concepts de base du test. Nous avons en 
particulier insiste sur le principe fondamental du test, qui est de reveler les fautes de 
I ' appl i cation afin de permettre I 'identification des defaillances. II est important de 
souligner le fait que, si aucune faute n'est revel ee, cela ne donne aucune garantie sur la 
non-existence de defaillances. Nous avons simplement identifies un ensemble de 
« donnees » ne provoquant pas de def ai 1 1 ance et n' avons aucune information sur ce qui 
se passe avec d'autres donnees. 
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Nous avons ensuite presents les concepts permettant la realisation du test. Nous avons 
notamment detail le les relations entre la specification de I'appl ication, le code de 
I 'application, les cas de test abstraits et les cas de test executables. 

Nous avons en outre montreen quoi les interactions UM L et les diagrammes de sequence 
pouvaient etre utilises pour specifier les cas de test abstraits. Pour ce faire, nous avons 
propose une facon d'utiliser les interactions afin de permettre une specification complete 
des cas de test. 

Pour finir, nous avons presents' une operation de generation de code de test a parti r des 
interactions detest. 

Nous pouvons des lors integrer tous ces mecanismes dans notre cycle de developpement 
avec U M L . 

La figure 7.3 schematise cette integration en mettant bien en evidence le fait que les 
parties structurelles et comportementales de bas niveau d'abstraction sont exploitees et 
offrent des gains de productivite pour le developpement de I 'application. En effet, si des 
fautes sont revelees apres I'execution des tests sur I'application, I' identification et la 
correction des defail lances peuvent se faire soitsur lecode, soitsur le modele. 



Travaux diriges 

TD7. Diagrammes de sequence de test 



La classe Parti e de I'application de gestion de championnat d'echecs presentee au TD6 
represente une partie d'echecs. Elle permet aux joueurs de jouer leur partie en appelant 
I'operation jouerCoupO. Chaque fois qu'un coup est joue, I'operation verifierMat( ) est 
appelee afin de verifier que la position n'est pas mat. Si tel est le cas, la partie est finie. 
Aucun coup ne peut alors etre joue (voirTD6 pour la moderation de classe Partie ainsi 
qu'un diagramme de sequence specifiant un cas nominal de deroulement d'une partie 
entre deux joueurs). 

Question 60. Identifiez une faute qui pourraitintervenirlors du deroulementd'une partie. 

Question 61. Definissez un cas de test abstrait visant a reveler cette faute. 

Question 62. Construisez un diagramme de sequence de test modelisant le cas de test 
abstrait de la question precedente. 

Question 63. Ecrivez le pseudo-code J ava du cas de test executable correspondant au 
cas de test abstrait de la question precedente. 

Question 64. Si ce cas de testne revele pas de faute, est-ce que cela signifie que I'appli- 
cation ne contient pas de defaillance ? 
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Question 65. Combien de cas de test faudrait-il elaborer pour ameliorer la qualite de 
I'application ? 

L'application permettant la gestion de championnat d'echecs contient 
aussi la classe ChampionnatDEchecs, qui est associee a la classe Partie et 
qui permet de gerer inscription des joueurs et la creation des parties (voir 
TD6). 

Question 66. Identifiez une faute qui pourrait intervenir lors de la creation des parties 
d'un championnat. Definissez un cas de test abstrait visant a reveler cette 
faute, et construisez un diagramme de sequence de test modelisant ce cas 
de test abstrait. 

Question 67. Est-il possible de lier les deux cas de test abstrait que vous avez definis 
(un a la question 61, 1'autre a la question 66) ? 

Ce TD aura atteint son objectif pedagogique si et seulement si : 



Vous savez identifier des fautes possibles. 

Vous savez definir les cas de test permettant de reveler les fautes. 

Vous avez conscience de la complexity de definir un jeu de tests complet. 
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Objectifs 

■ Definir la notion de plate-forme d'execution 

■ Presenter la fagon dont UML prend en charge les plates-formes 

■ Preciser comment et pourquoi s'abstraire des plates-formes d'execution 



J ava dans UML 

Depuisledebutdececours, tous les model es UM L que nous avons presenf.es etaient plus 
ou moins lies a J ava. II est cependant essentiel dedifferencier, dans un modele UM L, les 
elements qui dependent dej ava et les autres. 

Nous introduisons dans cette section les concepts de modele UML pour Java et de 
modele 100 % UML afin d'expliciter cette difference. 

Modeles 100% UML et modeles UML pour J ava 

Lorsque nous avons presente I 'operation de Reverse Engineering, nous avons explique, 
d'une part, que les classes de I'API Java etaient introduites dans le modele et, a" autre 
part, que le code J ava eta it integreau modele dans des notes attachees aux operations des 
classes. 

Lorsque nous avons presente I 'operation de generation de code, nous avons precise des 
contraintes sur les modeles. Ces contraintes ont ete definies afin d' assurer la generation 
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du code Java. E lies dependent done dejava. Par exemple, nous avons precise qu'il ne 
fallait pas que le modele UM L utilise I 'heritage multiple, car celui-ci n'etait pas supporte 
dans Java. 

Lorsque nous avons presente les interactions, nous avons precise des regies assurant leur 
coherence avec la partie structurel le du modele. Decefait, el les dependent aussi dejava. 
II est notamment envisageable que des objets participant aux interactions soient des 
objets instances des classes de I'A PI J ava. 

Pourfinir, lorsque nous avons presente la generation du code detest, nous avons utilise la 
plate-forme J Unit, qui est une plate-forme J ava. Les interactions de tests sont done el les 
aussi fortement dependantes de J ava. 

Pour resumer, les model es que nous avons realises depuis le debut de ce cours sont des 
modelesUML qui dependent dejava. Nous les appelons« modelesUML pourJava».A 
I'inverse, nous appelons « modeles 100% UML » les modeles independants de tout 
langage de programmation. 

UML productif ou perenne 

S'il existe deux sortes de modeles UML (modeles 100 % UML et modeles UML pour 
Java), il est important de bien comprendre ce qui les difference et d' identifier les gains 
que nous pouvons obtenir de chacun d'entre eux. 

N ous connaissons tres bien les modeles UML pour J ava, car ce sont les modeles que nous 
avons utilises depuis le debut de ce cours. Comme indique a la section precedents, la 
particularite d'un modele UML pour J ava est de dependre du langage de programmation 
Java. Cette particularite est autantun avantage qu'un inconvenient. 

L'avantage est que, grace a cette dependance, les operations de generation de code et de 
Reverse Engineering peuvent etre real i sees conjointement, garantissant ainsi une 
synchronisation entre le modele et le code d'une application. Grace a cette synchronisa- 
tion, il est possible d'obtenir a la fois les avantages des operations realisables sur les 
modeles (recherche et modification des dependances, generation de documentation, 
specification et generation des cas detest en coherence avec I ' appl i cati on) et les avanta- 
ges des operations realisables sur I e code (codage, compilation et execution). 

Les modeles UML pour J ava offrent done des gains de productivite vers le langage J ava. 

Cette caracteristiquedes modeles UM L pour J ava est aussi un inconvenient, en cequ'elle 
restreint les gains potentiels offerts par U M L uniquementa des gains de productivite vers 
le langage J ava. Pourautant, UML a ete defini historiquement afin defaci I iter la compre- 
hension et la conception d'applications orientees objet. La majorite des concepts UML 
ont ete defini s afin demieux apprehender la complexity de la construction deces applica- 
tions. Le concept d' association, par exemple, est tres interessant pour specifier les liens 
structurels existant entre les classes. Ce concept permet typiquement de gerer la 
complexity des applications mais n'offre pas de gains de productivite pour generer le 
code de I'application. 
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Les modeles UM L pour Java n'offrent done que peu de gains pour gerer la complexity 
des applications orientees objet. 

Comme leur nom I'indique, les modeles 100% UML sont quant a eux completement 
independants des plates-formes d'execution. Leurs avantages et inconvenients sont done 
essentiellement inverses a ceux des modeles UM L pour Java. 

Plate-forme d'execution 

La notion de « plate-forme d'execution » englobe a la fois les langages de programmation (Java, C++, C#, 
etc.) et les serveurs d'applications (J2EE, PHP, EJB, .Net, etc.). 

Le fait que les modeles soient independants des plates-formes d'execution fait que les 
informations qu'ils contiennent sont, par definition, independantes des changements 
internes des plates-formes. 

La plate-forme Java, par exemple, a deja change cinq fois de version en dix ans, avec des 
modifications assez importantes de I * A P I , qui necessitent une modification des modeles 
UML pour Java deja realises si I'application model isee doit pourvoir s'executer sur la 
nouvel I e plate-forme. Faire un modele 100 % UML permet de s'affranchir de ces modi- 
fications et done de rendre I'information beaucoup plus perenne. 

Faire un modele 100 % UML permet en outre, et surtout, de faire des choix de concep- 
tion independamment des plates-formes d'execution. II estainsi possible de commencer 
un developpement sans avoir, au prealable, choisi la plate-forme d'execution. 

Pour finir, soulignons que la perennite de I'information contenue dans un modele 100 % 
UML est plus facile a atteindre grace a I'emploi de tous les concepts UML construits 
specialement pour cela (association, objet non type, etc.). Rappelons que I'objectif 
premier d'UM L etait d'etre un langage de modelisation, et non un langage de program- 
mation. 

L'inconvenient des modeles 100% UML est toutefois de n'avoir aucun lien avec les 
plates-formes d'execution. Decefait, il esttres difficile de generer du code executable a 
partir d'un modele 100 % UM L. Si nous prenons I' exemple de la plate-forme Java, que 
nous connaissons deja, il est tres difficile de generer du code a partir d'un modele 100% 
UML utilisant I ' heritage multiple. 

Pour resumer, les modeles UM L pourjavaet les modeles 100% UML sontcomplemen- 
taires. Les modeles UML pour Java offrent des gains de productivity, tandis que les 
modeles 100% UML offrent des gains de perennite et facilitent la gestion de la 
complexity de la construction des applications orientees objet. II est done i nteressant de 
nepas les considerer comme des modeles independants, mais pi utot comme des modeles 
complementaires. 
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Niveaux conceptuel et physique 

Nous venons devoir que les model es 100 % UM L et les model es UM L pour Java etaient 
complementaires. En fait, les modeles 100% UML sont des abstractions des modeles 
UML pour Java, car ils masquent toutes les informations relatives a la plate-forme Java. 
Nous pourrions dire en outre que les modeles UML pour Java precisent les modeles 
100 % UM L en expli quant comment utiliser la plate-forme Java pour mettre en oeuvre la 
conception exprimee dans le model e 100 % UM L. 

Abstraction de la plate-forme 

Comme les modeles 100 % UML sont des abstractions des modeles UML pour Java, il 
est possible de definir une operation permettant de construire un model e 100 % UM L a 
parti r d'un model e UML pour Java. II suffit pour eel a de supprimer toutes les informa- 
tions relatives a la plate-forme Java. 

Les regies a appliquer pour construire un model e 100 % UM L a parti r d'un modeleUM L 
pour J ava sont I es sui vantes : 

1. Supprimer toutes les associations entre les classes qui n'appartiennent pas a I'API 
J ava et les classes qui appartiennent a I'A PI J ava. 

2. Supprimer toutes les classes de I'A PI Java. 

3. Si une proprieted' une classe qui n'appartient pas a I'A PI J ava a un type J ava, rempla- 
cer ce type par un type UML correspondant (il peut etre necessaire de definir la classe 
representant ce type s' il ne s'agit pas d' un type U M L de base). 

4. Si une operation d'une classe qui n'appartient pas a I'API Java a un parametrequi a 
un type Java, remplacer ce type par un type UML correspondant (meme remarque 
que pour les types des proprietes). 

5. Dans les interactions, supprimer les objets instances des classes de I'API Java. 

Ces regies draconiennes permettent d'obtenir un modele 100% UML a partir d'un 
model e UM L pour J ava. Cependant, il est important de noter que le modele 100 % UM L 
obtenu n'est pas reellement exploitable, car il necontient que des informations parti el I es 
et incompletes. II fautdonc I e completer en ajoutant des associations entres les classes ou 
en completant les interactions afin de bien specifier les informations principales de 
I'appl ication, aussi appelees informations metier. 

Les informations relatives aux parties graphiques de I 'application, qui sont obligatoire- 
ment dependantes de la plate-forme d' execution, sont, par exemple, entierement retirees 
du modele 100 % UM L. Le modele est des I ors i ndependant des changements internes de 
la plate-forme Java et peut etre reutilise pour d'autres realisations (vers la plate-forme 
.Net, par exemple). 

A I' inverse, il esttresdelicatdeconstruireautomatiquementun modele UML pour J ava 
a partir d'un modele 100 % UML. En effet, si le modele 100 % UML utilise des cons- 
tructions non supportees par la plate-forme J ava, il fauttraduire ces constructions afin de 
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les representer dans le modele UM L pour Java. Par exemple, si le modele 100 % UM L 
utilise I ' heritage multiple, il faut transformer tout heritage multiple en un ensemble 
d'heritages simple, ce qui est possible mais reste une operation tres delicate et tres 
complexe. 

De plus, construire automatiquement un modele UML pour Java a partir d'un modele 
100% UML ne peut se faire que si nous connaissons la signification des classes du 
modele 100 % UML afi n de bien identifier la partiede I 'A PI Java a utiliser. Par exemple, 
si nous savons que le modele 100 % UML definit une classe responsable de la sauve- 
garde sur disque, nous pouvons utiliser I'API Java dediee aux entrees- sorties 
(java.io.File). M alheureusement, il n'est pas possible de preciser ce niveau de detail des 
classes en UML. 

Pour toutes ces raisons, plutot que de generer automatiquement des model es UML pour 
Java a partir de model es 100 % UM L ou I'inverse, nous preconisons plutot de specifier la 
logique metier de I ' appl icati on a I'aided'un modele 100 % UM L et de specifier la reali- 
sation de cette logique metier sur une plate-forme d'execution particul iere (pour nous 
Java) a I'aided'un modele UM L pour Java. 

Definir la logique metier d'une application consiste, d'une part, a definir les informations 
princi pales manipulees par I 'appl icati on (objets metier) et, d' autre part, a definir les fonc- 
tions princi pales de I 'appl icati on (fonctions metier) en precisant leurs impacts en terme 
de modification sur les donnees. 

L'objectif d'un modele 100 % UML est done de representer la logique metier de I ' appl i - 
cation etnon d'expliquer comment eel a fonctionne dans J ava.Tous les objets et fonctions 
d'un modele 100 % UML ne se retrouvent done pas obligatoirement tels quels dans le 
modele UML pour Java correspondant. 

Niveaux d'abstraction 

Nous venons devoir que les model es 100 % UM L etUM L pourjavaetaientcomplemen- 
taires, que les uns etaient des abstractions des autres, et qu'il n'etait pas envisageable de 
passer des uns aux autres a I 'aide d' operations automatiques. 

De ce fait, il parait naturel de ne pas traiter ces modeles comme des modeles indepen- 
dents, mais plutot comme des parties d'un meme modele situees a differents niveaux 
d'abstraction. 

Nous considerons les deux niveaux d'abstraction suivants : 

• Niveau conceptuel. Correspond au niveau 100 % UM L. Ce niveau contient la logique 
metier de I ' appl i cati on, celle-ci etant specifiee d'une fagon independante de toute 
plate-forme d'execution. 

• Niveau physique. Correspond au niveau UML pourjava. Ce niveau contient la reali- 
sation de la logique metier sur une plate-forme d'execution particul iere, les informa- 
tions contenues a ce niveau etant dependantes de la plate-forme d'execution (J ava dans 
notre cas). 
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Ces deux niveaux sont lies, car le niveau conceptuel est une abstraction du niveau physi- 
que. Plus precisement, tous les elements du niveau conceptuel (classes, associations, 
interactions) doivent avoir au moins un element correspondant dans le niveau physique. 
Par contre, tous les elements du niveau physique ne sont pas forcement des concretisa- 
tions d' elements du niveau conceptuel, certains ayant pu etre ajoutes pour obtenir un 
modele a partirduquel il est possible deproduiredu code Java. 

Les liens entre ces niveaux ne sont pas obtenus par une operation de generation automa- 
tique. lis doivent etre precises par le concepteur du modele lors de la conception du 
model e. Cette tache peut etre ardue. Elle n'en est pas moins indispensable, car ces liens 
garantissent la coherence des informations situees aux deux niveaux d' abstraction. 

Cycle de developpement UML 

Notre cycle de developpement avec UML integremaintenantdeux niveaux d' abstraction. 
Le niveau physique est en coherence avec le code grace aux operations de generation de 
code et de Reverse Engineering. Le niveau conceptuel est en coherence avec le niveau 
physique grace aux relations d'abstraction specifiees par le concepteur du modele. Dans 
cette section nous expliquons comment integrer ces deux niveaux conceptuel s dans notre 
cycle de developpement UM L. 

Integration des deux niveaux dans le cycle 

Nous venons devoir que les model es 100 % UM L et les model es UM L pour Java etaient 
deux parties d'un meme modele, situees a deux niveaux d'abstraction differents. 

Ces niveaux d'abstraction correspondent aux deux niveaux d'abstraction les plus bas de notre 
vision schematiquedu modeleUM L d'une application. Lafigure8.1 ill ustre ces deux niveaux. 

Nous avons volontairement fait apparaitre un lien de coherence entre les parties structu- 
re! I es des niveaux conceptuel et physique. Ce lien peut etre specifies en UM L a I'aide 
d'une relation d'abstraction entre les classes situees dans ces deux niveaux. 

Cette relation d'abstraction peut apparaitre graphiquement sur un diagramme de classes 
a I'aide d'une fleche pointillee. Par contre, nous n'avons pas fait apparaitre de lien de 
coherence entre les parties comportementales des deux niveaux. Cela s'explique par le 
fait qu'UM L ne propose pas de concept permettant de representer graphiquement une 
relation d'abstraction entre deux interactions. 

Approches possibles 

Soulignons que les objectifs des niveaux physique et conceptuel sont complementaires. 
L'interetdu niveau conceptuel par rapport au niveau physique est deperenniser les infor- 
mations les plus importantes du modele (les informations metier). De plus, en faisant 
abstraction des specificites des plates-formes d'execution, la construction du niveau 
conceptuel permet de mieux apprehender la complexity de la construction des applica- 
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Figure 8.1 

Niveaux d' abstraction « physique » et « conceptuel » dans le modele U M L 



Niveau conceptuel 



Niveau physique 



tions orientees objet. Contrairement au niveau physique, le niveau conceptuel n' off re 
done pas de gain de productivity reellement quantifiable. 

C'est pourquoi nous ne preconisons I'elaboration du niveau conceptuel que s'il y a un 
reel interet soit a perenniser les informations metier (si un changement de plate-forme 
d'execution est envisage), soit a gerer la complexity de I'application en faisant abstrac- 
tion des details techniques. 

II est vrai que ces interets se retrouvent principalement dans le contexte de la construc- 
tion d'applications relativement complexes, dont la taille depasse dix mille lignes de 
code. Pour les autres applications, dont la taille est inferieure a dix mille lignes de code, 
I'interet de disposer d'un niveau abstrait disparatt devant la difficulty a mettre en ceuvre 
les relations de coherence avec le niveau physique. 

Les deux approches envisageables pour suivre un cycle de developpement avec UM L 
sont done soit de mettre en ceuvre le niveau conceptuel, soit de s'en passer. II serait 
contre-productif de vouloir mettre absolument en oeuvre le niveau conceptuel si aucun 
benefice ne pouvait en etre retire. 
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Synthese 

Nous avons vu dans ce chapitre que les modeles que nous avons presented jusqu'ici 
etaient fortement dependants de la plate-forme Java. Forts de ce constat, nous avons 
introduit la notion de modele pour Java et de modele 100 % UM L. 

Nous avons montre que les modeles pour Java et les modeles 100 % UML etaient 
complementaires et qu'ils offraient des gains differents. Les modeles pour Java 
apportent des gains de productivity tandis que les modeles 100 % UML apportent des 
gains de perennite et de gestion de la complexity 

Nous avons ensuite precise la relation d' abstraction qui existait entre ces deux 
niveaux. Les modeles 100 % UML sont des abstractions des modeles UML pourjava, 
car ils masquent les details techniques de la plate-forme Java. Ainsi, les modeles 
100 % UM L specifient la logique metier de I'application, alors que les modeles UM L 
pour Java specifient la facon dont est uti I i see la plate-forme Java pour real iser 
I'application. 

Nous avons en outre explique pourquoi il eta it plus naturel de considerer ces deux 
types de modeles non pas comme des modeles independants, mais comme des parties 
differentes d'un meme modele, situees a differents niveaux d'abstraction. Nous avons 
alors precise comment ces deux niveaux d'abstraction (conceptuel et physique) etaient 
integres a notre vision schematiquedes modeles UM L d'applications. 

Pour finir, nous avons introduit les deux fagons envisageables de suivre un cycle de 
developpement avec UML, en precisant qu'il n'etait pas obligatoire de mettre en 
ceuvre le niveau conceptuel; tout dependant des benefices que nous souhaitions obtenir 
du modele U M L. 



Travaux d i r iges 

TD8. Plates-formes d'execution 



Question 68. Le diagramme de I'agence de voyage represents a la figure 8.2 corres- 
pond-il a un modele conceptuel ou a un modele physique ? 

Question 69. Pensez-vous qu'il soit interessant d'appliquer des patrons de conception 
sur les modeles conceptuels ? 

Question 70. Le diagramme de sequence represents a la figure 8.3 est-il conceptuel ou 
physique ? Vous noterez qu'il fait intervenir une operation qui n'apparait pas 
dans le diagramme de classes initial. Quelle classe doit possSder cette 
operation ? 
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Figure 8.2 

Diagramme 
de I'agence 
de voyage 



Hotel 


hotel 


Reservation 


-dateArrivee:string 
-dateDepartstring 


-name:string 


< 

0..1 * 




-BetHoteK) 



hotelPropose 



reservationEffecWee 



AgenceDeVoyage 



+obtenirReservation() 
+demanderTarife() 



client: 



aa:AaenceDeVovage 



obtenirReservation("R itz","15juin ","16juin " 



ok 



creation 



resa:Reservation 



addReservationEffectuee(resa) 



Figure 8.3 

I nteraction representant une reservation 



Question 71. Serait-il possible de specifier en « 100% UML» le comportement de 
I'agence de voyage ? 

Question 72. Serait-il possible de specifier en « 100 % UML » des tests pour I'agence 
de voyage ? J ustifiez I'interetde ces tests. 

Question 73. Le diagramme represents a la figure 8.4 est une concretisation du 
diagramme conceptuel de I'agence de voyage. Exprimez les relations 
d'abstraction entre les elements des deux diagrammes. 
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Figure 8.4 

Classes du niveau physique de I'agence de voyage 



\ 

Reservation res^iull; 

for (Iterator it = reservationEffectuee. iteratorO ; it.hasNextO ; ) { 

Reservation current=(Reservation) it.next(); 

if {currentdateArrivee =dateArrivee 
&&current.dateDepart= dateDepart 
&&current.hotel.name = hotelName) return current 

} 

res = new Reservation(dateArrivee , dateDepart); 
res.setHotel(new HoteO); 
return res 



Question 74. Quel est I'interet d'avoir fait apparaitre les classes ArrayList et iterator 
dans le modele concret (considerez en particulier la generation de code et 
le Reverse Engineering) ? 

Question 75. Construisez le diagramme de sequence concretisant le diagramme de 
sequence presente a la question 69. 

Question 76. Exprimez les relations d'abstraction entre les diagrammes de sequence. 



Ce TD aura atteint son objectif pedagogique si et seulement si : 

• Vous savez differencier des modeles conceptuels et des modeles physiques. 

• Vous savez etablir des relations d'abstraction entre modeles de niveau different. 

• Vous avez conscience que plus le modele physique est proche de la plate-forme 
d'execution, plus il est loin du modele conceptuel (et inversement). 
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de cas d'utilisation 



■ Presenter les concepts UML relatifs a la vue fonctionnelle (diagramme de cas d'utilisation) 

■ Presenter la notation graphique du diagramme de cas d'utilisation 

■ Expliquer la semantique des cas d'utilisation UML en precisant le lien avec les 
interactions UML 



Vue fonctionnelle du modele UML 

La partie fonctionnelle du modele UML d'une application permet de specifier les fonc- 
tionnalites offertes par I ' appl icati on sans pour autant specifier la fagon dontcesfonction- 
nalites sont real i sees par les objets de I ' appl i cation. 

Fonctionnalites d'une application orientee objet 

Le principe fondateur du paradigme objet est de reunir en une seule et meme entite, 
I 'objet, des donnees et des traitements. A I'epoque de la creation de ce paradigme, ce 
principe etait considere comme revolutionnaire, car il allait a rebours des paradigmes 
existants (fonctionnel et donnees), qui visaient a separer les donnees et les traitements 
dans des entites differentes. 
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L' avantage I e pi us i mportant qu' apporte ce pri nci pe fondateur est de permettre I ' i dentifi- 
cation, la decomposition et la reuti I isation d'entites capables de realiser des traitements 
uniquement grace aux donnees qu'elles possedent. Avec le paradigme objet, il est possi- 
ble deconsiderer une application commeun ensemble d'objets independants maiscohe- 
rents, chacun real i sant la tache pour laquelle il a ete congu. Ainsi, si une tache real i see 
par un objet est necessairedans une autre application, il est possible de reuti I i ser I'objet. 

L' inconvenient de ce pri nci pe fondateur est qu'il masque les fonctionnal ites offertes par 
desgroupes d'objets. En effet, leur specification n'est pas expli cite et est repartie dans les 
traitements et dans les interactions realises par chacun des objets participant au groupe. 
De cefait, il est tres difficile de specifier les besoins fonctionnels que nous avons sur une 
application a I' aide d'objets. Ces besoins fonctionnels, qui s'expriment naturellement a 
I'aide de fonctions, ne peuvent done etre exprimes simplement sous forme de groupes 
d'objets. 

Par exemple, si nous voulions specifier a I'aide d'objets les besoins fonctionnels d'une 
application de gestion de prets bancaires tels que la creation d'un pret ou le calcul d'un 
taux d'interet, il faudrait specifier I'ensemble des objets participant a la realisation de 
I'application et specifier chacun des traitements associes a ces objets. Si cela reste faisa- 
ble, cen'estguerenaturel pour nous developpeurs, pi utot habitues a utiliser ledecoupage 
fonctionnel. 

Pour resoudre ce probleme et reconcilier le paradigme objet avec la possibility d'expri- 
mer les besoi ns d' une appl ication sous forme de fonctions, UML definit le concept de cas 
d' utilisation. 



Concepts elementaires 

Cette section presente les concepts elementaires de la vue fonctionnelle d'un modele 
U M L . Dans notre contexte, ces concepts sont suffi sants pour exprimer les fonctionnal ites 
d'une application. 

Cas d'utilisation 

Semantique 

Un cas d'utilisation specifie une fonction offerte par I'application a son environnement. 
Un cas d'utilisation est specifie uniquement par un intitule. 

Nous recommandons que I 'intitule du cas d'utilisation respecte le pattern 
« verbe + complements ». Le verbe de I' intitule permet de specifier la nature de la fonc- 
tionnal ite offerte par I'application, tandis que les complements permettentde specifier les 
donnees d' entree ou de sortie de la fonctionnal ite. 

Par exemple, le cas d'utilisation « calculer taux d'interet du pret » permet decomprendre 
d'une certaine maniere que I'application permet a ses utilisateurs de calculer le taux 
d'interet d'un pret. 
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Le concept de cas d'utilisation offre une vue fonctionnelle sur I'application. La facon 
dont sera realiseconcretementun cas d'utilisation n'apparait pas dans la definition du cas 
d' uti I i sati on . E 1 1 e sera preci see par la suite, I ors de I ' etabl i ssement des I i ens de coherence 
avec les autres parties du model e. 

Graphique 

Un cas d'utilisation se represente par une ellipse contenant I' intitule du cas d'utilisation. 

La figure 9.1 represente le cas d'utilisation que nous avons introduit a la section prece- 
dente. 



Figure 9.1 

Representation 
graphique d'un cas 
d'utilisation 



Calculer taux 
sd'interet du prety 



Acteur 

Semantique 

Un acteur represente une entite appartenant a I'environnement de I'application qui inte- 
ragitavec I'application. 

Le concept d' acteur permet de classifier les entites externes a I'application. U n acteur est 
identifie par un nom. 

Graphique 

Un acteur se represente par un petit bonhomme et un nom (nom du role). 
L a figure 9.2 represente I 'acteur ci i ent. 

Figure 9.2 

Representation 
graphique 
d'un acteur 



Systeme 

Semantique 

Un systeme represente une application dans le modele UM L. II est identifie par un nom 
et regroupe un ensemble de cas d'utilisation qui correspondent aux foncti onnal ites offer- 
tes par I'application a son environnement. 

L' envi ronnement est specifi e sous forme d' acteurs I i es aux cas d' uti I i sati on. 
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Graphique 

Un systemese represente par un rectangle contenant le nom du systemeet les casd' utili- 
sation del'application. 

Les acteurs, exterieurs au systeme, sont represents et relies aux cas d'utilisation qui les 
concernent. L' ensemble correspond a un diagrammede cas d'utilisation. 

La figure 9.3 represented diagrammede cas d'utilisation d'une application degestion de 
prets bancaires avec son unique cas d'utilisation offert a I'acteur qui represente I e client. 



Figure 9.3 

Diagrammede cas 
d'utilisation 



Client 



Gestion de prets bancaires 




Liens avec les autres parties du modele 

Nous venons de voir que la partie fonctionnelle du modele UML permettait de specifier 
les foncti onnal ites d'une application mais aussi de preciser a quel les entites externes ces 
fonctionnalites sont offertes. 

II est possible d'elaborer plusieurs diagrammes de cas d'utilisation a chaque niveau 
d'abstraction permettant de regrouper les fonctionnalites de I ' appl i cati on en differents 
sous-systemes. Cependant, nous considerons dans ce cours qu'il suffit d'elaborer un 
unique diagramme de cas d'utilisation par niveau d'abstraction. Ce diagramme repre- 
sente les fonctionnalites princi pales de I 'application a un niveau d'abstraction donne et 
les principaux beneficiai res de ces fonctionnalites. II correspond en quelque sorte a 
I 'emballage commercial des applications vendues en grande surface, sur lequel sontecri- 
tes les fonctionnalites offertes par I ' appl i cati on a ses utilisateurs. 

N ous savons que les fonctionnalites d' une appl ication orientee objet sont real i sees par les 
objets qui composent I 'appl ication. Ces objets sont specifies a I'aide des classes presen- 
tes dans la partie structurelle du modele de I ' appl i cati on, alors que les fonctionnalites 
sont specifiers dans la partie fonctionnelle du modele. II est done necessaire de faire 
apparaitre un lien de coherence entre les parties structurelle et fonctionnelle du modele 
UML afin de savoir quels sont les objets real isant telle ou telle foncti onnal ite. 

Pour etablir ce lien entre les parties structurelle et fonctionnelle du modele UML, nous 
preconisons d'utiliser les interactions presentes dans la partie comportementale du 
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modele de I ' appl icati on. L'idee sous-jacente est de faire correspondre a chaque cas 
d'utilisation uneou plusieurs interactions specifiant un exemplede realisation dela fonc- 
tionnalite. Ainsi, les cas d'utilisation sont en coherence avec les interactions, lesquelles 
sont en coherence avec les classes, puisque les objets qui apparaissent dans les interac- 
tions sont types par des classes specifiees dans la parti e structurel I e du modele. 

Plus precisement, nous preconisons de realiser pour chaque cas d'utilisation : 

• au moins une interaction specifiant I' execution normale de I ' appl icati on ; 

• une interaction specifiant les executions soulevant des erreurs de I ' appl i cation. 

La figure 9.4 il lustre les relations de coherence entre les parti es fonctionnelle, comporte- 
mentale et structurelle du modele d'une application. Nous constatons que les cas d'utili- 
sation du diagrammedecas d'utilisation sont relies a des diagrammes de sequence et que 
les objets de ces diagrammes de sequence sont relies a des classes. 

Par rapport a notre vision schematiquedu modele UM L d'une application, ces liens entre 
les vues fonctionnelle, comportementale et structurelle existent a chacun des niveaux 
d'abstraction du modele. Nous verrons au chapitre 10 de ce cours comment mettre en 
oeuvre les relations de coherence entre les differents niveaux d'abstraction. 

Dans chacune de ces interactions, nous preconisons de faire apparaitre les objets correspon- 
dent aux acteursqui utilisent la foncti onnal ite. II estd'ailleurs possible de faire en sorteque 
I e type d'un objet participant a une interaction soit un acteur (et non une classe). 

A fin d'ameliorer la visibility des diagrammes de sequence representant ces interactions, 
nous preconisons de faire apparaitre les objets representant des acteurs a gauche du 
diagramme. De plus, nous preconisons de reutiliser, autant que possible, les memes 
objets dans toutes les interactions specifiees. Cela donne une meilleure visibility au 
modele en ne multi pliant pas inutilement le nombredes objets. 

Notons qu'il est possible d'exploiter ces interactions afin de definir des interactions de 
test (voir le chapitre 7), ce que nous neferons pas dans le cadre dece cours. 



Concepts avarices 

Les concepts avances que nous presentons dans cette section permettent de specifier plus 
finement les fonctionnalitesetl'environnement d'une application. Ces concepts sonttoute- 
fois si delicats a employer que nous deconseillons fortement leur utilisation. Nous ne les 
presentons qu'afin de completer notre presentation du diagramme de cas d'utilisation. 

Soulignons en outre que ces concepts n'ont quasiment pas evolue entre les versions 
UML 1.4etUML 2.1. 

Concepts avances relatifs aux cas d'utilisation 

Cette section presente les concepts avances applicables aux cas d'utilisation. Ces 
concepts sont essentiellement des relations entre cas. 
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Figure 9.4 

Liens de coherence entre les vues d'un modele 



include 

Semantique 

II est possible de specifier qu'un cas d' utilisation inclutun autre cas d'utilisation. 

Etant donne que les cas d'utilisation correspondent a des fonctions, la relation d'inclu- 
sion entre deux cas d'utilisation peut etre comparee a une relation d'inclusion de fonc- 
tions. En d'autres termes, si un cas d'utilisation C2 herite d'un cas d'utilisation CI, 
I'execution deCl faitappel a C2. 



Diagrammes de cas d'utilisation 




Chapitre 9 



La relation d'inclusion entre cas d'utilisation doit cependant etre employee avec parci- 
monie. L' ideal estden'y recourirquelorsqu'un cas d'utilisation estinclusdansau moins 
troisou quatre autrescas, carcela permet de f actori ser I e cas i ncl us. 

Soulignons le fait que la relation d'inclusion ne doit pas etre utilisee pour exprimer une 
decomposition fonctionnelle entre plusieurs cas. En effet, la relation d'inclusion ne 
permet pas de preciser une quelconque relation d'ordre ou de priorite d'appel entre les 
cas inclus. 



La relation d'inclusion entre cas d'utilisation se represente graphiquement a I 'aided' une 
fleche pointillee sur laquelle nous faisons apparaitre la chaine de caracteres « include ». 
La fleche va du cas qui inclutvers le cas inclus. 

La figure 9.5 represente une relation d'inclusion entre deux cas d'utilisation. 



extend 

Semantique 

II est possible de specifier qu'un cas d'utilisation etend un autre cas d'utilisation. 

Cela signifie en quelque sorte qu'un comportement qui n'etait pas specifies est ajoute au 
cas etendu. La relation d'extension est souvent utilisee pour preciser des fonctionnalites 
optionnelles qui sont ajoutees aux fonctionnalites de base. 



La relation d'extension entre cas d'utilisation se represente graphiquement a I 'aided' une 
fleche pointillee sur laquelle nous faisons apparaitre la chaine de caracteres « extend ». 
La fleche va du cas qui etend vers le cas etendu. 

La figure 9.6 represente une relation d'extension entre deux cas d'utilisation. 



Graphique 



Figure 9.5 

R el ati on d' i ncl usion 
entre cas 
d'utilisation 




Graphique 



Figure 9.6 

Relation 

d'extension entre 
cas d'utilisation 
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Heritage 

Semantique 

II est possible de specifier une relation d' heritage entrecas d'utilisation. 

Si un cas d'utilisation CI herite d'un cas d'utilisation C2, C2 peut etre substitue a CI 
pour un acteur qui souhaite beneficier de CI. Cette semantique restetoutefois ambigue, 
car les conditions de substitution ne sont pas specifiers. C'est pourquoi nous decon- 
seillons vivement I ' utilisation de cette relation. 

Graphique 

Comme I 'heritage entre classes, la relation d' heritage entre cas d'utilisation se represente 
graphiquementpar une fleche allant du cas d'utilisation qui herite vers le cas d'utilisation 
herite. 

La figure 9.7 represente une relation d'heritage entre deux cas d'utilisation. 




Concept avance relatif aux acteurs 

Cette section presente un concept avance applicable aux acteurs. Nous choisissons ici de 
ne presenter que la relation d'heritage, car cette relation est employee dans certains 
diagrammes. 

Heritage 

Semantique 

II est possible d'exprimer une relation d'heritage entre deux acteurs. 

L a signifi cati on de cette rel ati on d' fieri tage est sensi bl ement I a meme que eel I e de I a rel a- 
tion d'heritage entre classes (voir le chapitre 2). Si un acteur A 1 herite d'un acteur A2, 
cela signifie que toutes les entites externes correspondant a A 1 correspondent aussi a A 2. 

II est important de souligner que cette relation est ensembliste (tous les A 1 sont des A 2). 
De cefait, el I e ne doit pas etre employee si nous voulons exprimer qu'une entite externe 
peut correspondre a deux acteurs differents. Par exemple, si les acteurs « client » et 
« caissier » ont ete definis et que nous voulions exprimer qu'un caissier peut etre un 
client, il nefaut surtout pas utiliser la relation d'heritage. 



Diagrammes de cas d'utilisation 
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Graphique 



Comme la relation a" heritage entre classes, la relation d'heritage entre acteurs se repre- 
sente par une fleche allant de I'acteur qui herite vers I'acteur herite. 

La figure 9.8 represente une relation d'heritage entre I'acteur ci 1 entPri vil egi e et I 'acteur 

CI ient. 



Nous avons detaille dans ce chapitre la partie fonctionnelle d'un modele UM L. Cette 
partie permet de representer les differentes fonctionnalites offertes par I ' appl i cation a 
son environnement. II s'agit de la derniere des trois parties du modele UM L que nous 
voulions introduire dans ce cours. 

II est important derappeler que si UML propose d'autres parties, nous avons choisi de 
ne pas les presenter afin de nous concentrer sur les parties indispensables a la mise en 
oeuvre d'un cycle de developpement avec U M L tel que nous le concevons. 

Nous avons ensuite presente les liens de coherence qui existent entre les parties 
fonctionnelle, comportementale et structurelle. Ces liens de coherence ajoutes aux 
operations de synchronisation avec le code permettent d'obtenir a la fois les gains des 
operations de model isation a tous les niveaux d'abstraction et les gains des operations 
real isables sur le code. C'est ce que nous cherchions a obtenir des le debut de ce cours. 

Pour finir, nous avons introduit les concepts avances de la partie fonctionnelle d'un 
modele UML, en insistant bien sur le fait que ces concepts etant tres delicats a 
employer, il nefallaity recourirqu'en cas de reel I e necessite. 

Le prochain et dernier chapitre de ce cours s'interesse a un moyen methodologique 
permettant de comprendre un peu mieux comment mettre en place un cycle de 
developpement UM L. 



Figure 9.8 

Relation d'heritage 
entre acteurs 




C lientP rivilegie 



Synthese 
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Travaux diriges 

TD9. Diagrammes de cas d'utilisation 



Le diagramme de cas d'utilisation de la figure 9.9 represents les fonctionnalites d'une 
agence de voyage classique. 



Voyageur 



Agence De Voyage 




Figure 9.9 

Diagramme de cas d'utilisation de I 'agence de voyage 



Question 77. 
Question 78. 



Question 79. 
Question 80. 
Question 81. 
Question 82. 



Commentez les acteurs du diagramme de cas d'utilisation. 

Commentez les cas d'utilisation du diagramme de cas d'utilisation. 

Nous souhaitons realiser le diagramme de cas d'utilisation du cham- 
pionnat d'echecs presents au TD6. 

Donnez la liste des acteurs du systeme. 

Donnez la liste des cas d'utilisation du systeme en les liantaux acteurs. 

Donnez le diagramme de cas d'utilisation du systeme. 

Reprenez les diagrammes de sequence realises au TD6 pour I'application 
de championnat d'echecs, et expliquez comment les relierau diagramme 
de cas d'utilisation obtenu a la question precedents. 



Ce TD aura atteint son objectif pedagogique si et seulement si 



Vous arrivez a differencier les fonctionnalites de base d'une application et son 
organisation fonctionnelle (difference entre les niveaux besoin et conceptuel). 



Diagrammes de cas d'utilisation 
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• Vous savez etablir un diagramme de cas d'utilisation d'une application a partir de 
la description textuelle de cette derniere. 

• Vous savez faire le lien entre un diagramme de cas d'utilisation et les diagrammes 
de sequence d'une application au niveau besoin. 
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Objectifs 

■ Presenter les principes d'un support methodologique 

■ Proposer une methodologie simple de support au developpement avec UML 

■ II lustrer I'interet d'UML pour le developpement 



Analyse et conception 

Nous avons deja indique au chapitre 1 que la final ite de I ' activite de developpement eta it 
defournir une solution informatique a un probleme pose par un utilisateur, aussi appele 
client. Nous avons precise que lecode n'etait que la materialisation de la solution, tandis 
que le modele contenait toutes les informations facilitant d'une maniere ou d'une autre la 
construction de la solution. 

A pres cette introduction aux vues essenti el I es d'un modele U M L (structure! I e, comporte- 
mentale et fonctionnelle) d'une application, il nous reste a presenter la fagon dont nous 
devons utiliser chacune de ces parties afin de real i ser notre objectif : la realisation de la 
solution a parti r du probleme. 

Pour atteindre cet objectif, I'ingenierie logiciellea i dentifie depuis plusieurs anneesdeux 
phases princi pales a real i ser : I'analyse du probleme et la conception de la solution. 
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Analyse du probleme 

La phase d'analyse sert a modeliser la comprehension du probleme pose par le client. 
Cette phase sert aussi a bien definir les contours de I'application. 

Grace a la phase d'analyse, nous savons ce qui doit etre integre dans la solution, mais 
aussi ce qui nedoit pas I ' etre, puisque la solution nedoit prendre en comptequece qui a 
ete identifies lors de I'analyse. Ideal ement, une analyse doit etre realisee par I'equipe de 
developpement et validee par le client, lequel certifie ainsi que I'equipe de developpe- 
ment a bien compris son probleme. 

Danscecours, nous considerons que le probleme du client est specifie dans un cahier des 
charges. Le cahier des charges est un document textuel fourni par I e client, mais qui n'est 
pas integre dans le modele d'une application. Dans notre contexte, la phase d'analyse 
consiste a modeliser tous les besoins presents dans le cahier des charges. 

U ne analyse est complete lorsque I'i ntegralite du probleme est model isee de maniere non 
ambigue. 

Pour modeliser un cahier des charges avec UML, nous considerons que seules deux 
parties du modele UML sont i nteressantes, les parties fonctionnelle et structurelle : 

• La parti e fonctionnelle permet de specifier les fonctionnalit.es real i sees par I'applica- 
tion (casd'utilisation) ainsi que les contours de I'application (acteurs). 

• La partie structurelle permet de specifier sous forme d'objets les donnees que doit 
manipuler I'application. 

Ces deux parties du modele UML sont suffisantes pour modeliser les besoins du client 
exprimes dans le cahier des charges. Cependant, afin de bien preciser les liens de cohe- 
rence entre ces deux parties, nous utilisons aussi la partie comportementale, commenous 
I'avons montreau chapitre precedent. Cette partie permet en effetde lier les casd'utilisa- 
tion aux interactions; elles-memes liees aux classes. 

Dans le cadre de notre vision schematique du modele UML d'une application, nous 
considerons que la phase d'analyse correspond a un niveau d'abstraction que nous appe- 
lons le niveau besoin. 



Conception de la solution 

La phase de conception consiste a modeliser une solution qui resout le probleme mode- 
lise dans la phase d'analyse. 

Contrairementa cequenouspourrionscroire, fourni r une solution informati que n'est pas 
cequ'il y a de plus difficile : c'estjusteun probleme algorithmique. Parcontre, il est bien 
plus complique de fournir la meilleure solution au probleme, car, a un probleme donne, 
correspondent bien souvent plusieurs solutions. 

Prenons I'exemple du tri. II existe plusieurs facons de trier des elements (tri iteratif, tri a 
bulles, tri rapide, etc.). Toutes ces solutions resolvent le probleme du tri d'un point de vue 
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algorithmique, mais elles ne sont pas toutes equivalentes, et nous savons tres bien que 
certaines sont meilleures que d'autres. 

Pour differencier les solutions, deux criteres sont bien connus : la complexity en espace 
et la complexity en temps. Ces criteres permettent d'etablir un classement des solutions 
en fonction dela place memoirequ'elles occupentet du temps qu'elles mettenta real iser 
letraitement. 

D'autres criteres, plus adaptes au monde industriel et au paradigme objet, permettent 
d'effectuer d'autres classements des solutions. Citons notamment la maintenabi lite, la 
portability la robustesse, la rapidite de developpement, le cout de developpement, etc. 
Cette liste non exhaustive de criteres montre que la construction d'une solution optimale 
est loin d'etre triviale. 

Pour etre pragmatique, mais aussi pour simplifier la difficulty de la phase de conception, 
nous considerons dans le cadre de ce cours qu'une conception optimale est une concep- 
tion qui maximise I'independance a I'egard des plates-formes techniques et minimise les 
dependences entre les differents objets de I ' appl i cati on. 

A ces deux objectifs, nous faisons naturellement correspondre les deux niveaux 
d'abstraction que nous avons introduits au chapitre 8. En effet, nous avons vu que le 
niveau conceptuel permettait de definir une conception independante des plates-formes 
d'execution. Nous avons vu en outre au chapitre 4 qu'il etait possible de minimiser les 
relations de dependence entre les packages du niveau physique. 

Comment passer du quoi au comment ? 

De maniere intri nseque, I'analyse et la conception sontfondamentalement differentes, la 
premiere correspondant a la model isati on du probleme, etla secondea la model isati on de 
la solution. II existe entre ces deux niveaux une relation de resolution, puisque la concep- 
tion resout I'analyse. 

II est important de souligner qu'il ne s'agit pas la d'une relation d'abstraction telle 
qu'elle existe entre les niveaux d'abstraction conceptuel et physique. La solution (define 
par la conception) n'est pas la concretisation d'un probleme (defini par I'analyse) surune 
plate-forme particuliere. II existe une reel I e difference entre le probleme et la solution. 
C'est d'ailleurs la ou I e travail du developpeur prend tout son sens : fournir la meilleure 
solution susceptible de repondeau probleme. 

Pour autant, le fait que I'analyse et la conception tirent parti du paradigme objet et que la 
solution soit, par definition, « la solution du probleme » rendent quelque peut confuse 
cette difference pourtant fondamentale. En effet, le modele d'analyse contient des clas- 
ses, lesquelles definissent la structure et le comportement des objets du probleme. Or, il 
n'est pas rare de trouver dans la solution des classes aux structures et aux comportements 
relativement voisins. 

Prenons I'exemple d'une application de gestion de prets bancaires. Le modele d'analyse 
definit la classe Pret. Cette classe definit la structure et le comportement des prets tels 
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que pergus dans I e probleme. Cette classe permet, par exemple, de renseigner le montant 
du pret ainsi que son taux. Or, il est a parier que la solution exploite elle aussi la classe 
Pret et que cette classe ressemble« fortement » a la classe appartenantau probleme. Pour 
autant, cette relation etroite etablie entre les classes d'analyse et les classes de conception 
ne doit pas faire oublier que ces deux phases ont des objectifs fondamentalement cliff e- 
rents. 

A fin defaciliter le passage de la phase d'analyse a la phase de conception, nous preconi- 
sons d' identifier au niveau conceptuel lesgros composants de I ' appl i cati on. 

Un gros composant, represents a I'aide d'un package, est une entite relativement auto- 
nome, responsable d'une partie des traitements necessaires au bon deroulement de 
I ' appl i cati on. A titred'exemple, nous pouvons mentionner, pour I ' appl i cati on degestion 
de prets bancaires, un composant responsable des traitements graphiques del 'application 
(affichage des resultats, presentation des formulaires de saisie, etc.), un composant 
responsable de la sauvegarde des prets sur disque dur (sauvegarde sur fichier, chargement 
a partir d'un fichier, etc.) et un composant responsable du calcul des taux et de la valida- 
tion de I 'acceptation du pret. 

Chaque composant joue un role specifique dans I ' appl i cati on, et I'ensemble des compo- 
sants est responsable de toutes les fonctionnalites de I 'appl i cation (exprimees dans la 
phase d'analyse). La decoupe en composants d'une application est une operation deli- 
cate, qui reste a I a charge du developpeur. C'est la que reside la relation de « resolution » 
entre le niveau analyse et le niveau conception. 

Dans le modele UM L de I ' appl i cati on, les composants sont specifies au niveau concep- 
tuel. Chaque composant est sped fie par une partie fonctionnel I e, qui represente les fonc- 
tionnalites du composant offertes a son environnement, une partie comportementale, qui 
represente des exemples de realisation des fonctionnalites du composant, et une partie 
structure! I e, qui represente les classes du composant. 

De plus, toujours au niveau conceptuel, mais de fagon transverse a tous les composants, 
la partie structurelle du modele specifie les relations de dependance entre les compo- 
sants. Celles-ci sont exprimees sous forme de dependance entre les packages represen- 
tantles composants. 

UM L ne proposant aucun concept pour specifier une relation de « resolution » entre les 
niveaux besoin et conceptuel, nous preconisons d'utiliser des notes de commentaires 
integrees dans le niveau conceptuel. 

Chaque note de commentaires, attachee a un element de n'importe quel type (classe, 
association, objet, message, cas d' utilisation, acteur, etc.), doit identifier les elements du 
niveau besoin specifiantle probleme en partie resolu. 

Nous preconisons de preciser les relations de « resolution » pour chaque composant du 
niveau conceptuel. 

Plus precisement, nous preconisons, d'une part, d'attacher aux cas d'utilisation de 
chaque composant une note ciblant les cas d'utilisation du niveau besoin que le compo- 



Developpement avec UML H 

CHAPITRi~10 _ H 

sant resout et, d' autre part, d'attacher aux classes ou aux packages de chaque composant 
une note ciblant I es classes du niveau besoin que I e composant resout. 

La figure 10.1 illustre ces relations de resolution entre le niveau besoin et le niveau 
conceptuel. La figure fait apparattre deux gros composants dans le niveau conceptuel. 
Chacun de ces gros composants est specifie a I'aide d'un diagramme de cas d' utilisation, 
d'un ensemble de diagrammes de sequence et d'un diagramme de classes. Les relations 
de resolution sont schemati sees a I'aidedefleches entre les niveaux besoin et conceptuel. 




Niveau besoin 



Niveau conceptuel 

Figure 10.1 

Relation de resolution entre le niveau besoin et le niveau conceptuel 

En resume, selon notre vision schematique du modele UML d'une application, nous 
considerons que : 

• L'analyse correspond a un niveau d'abstraction « besoin ». 

• La conception correspond a deux niveaux d'abstraction : le niveau conceptuel et le 
niveau physique. Le niveau conceptuel specifie les differents composants de Implica- 
tion. Le niveau physique specifie la facon dont ces composants sont realises sur la 
plate-forme technique (J ava dans notre cas). 

• II existedes relations de resolution entre le niveau besoin et le niveau conceptuel. Ces 
relations sont exprimees a I'aide decommentaires dans le niveau conceptuel. 
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• II existe des relations d' abstraction entre le niveau conceptuel et le niveau physique. 
Ces relations sontexprimees a I 'aide de la relation d'abstraction entre les classes (voir 
le chapitre 8). 

Grace a ces relations entre toutes les parties du model e U ML et les phases d' analyse et de 
conception, nous pouvons completer notre vision schematique d'un cycle de developpe- 
ment avec UML comme i 1 1 ustre a la figure 10.2. 



VUES 



Structure 



Comportement 



CODE 



Fonctionnalite 



COHERENCE 



Generation de code et 
Reverse Engineering 




eneration de code de 
test 



J Unit 



TEST 



Execution des tests 



Figure 10.2 

Cycle de developpement avec UML (version complete) 



ANALYSE 



Niveau besoin 



Niveau conceptuel 



N iveau physique 



CONCEPTION 



Methode de developpement 

Comme explique au chapitre 1, une methode de developpement doit repondre aux ques- 
tions suivantes : 

• Quand real iser une activite ? 

• Qui doit real iser une activite ? 

• Quoi faire dans une activite? 

• Comment realiser une activite? 
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M aintenant que nous avons presente toutes les parties du model e UML d'une application, 
nous savons ce que propose UML pour repondre aux questions du quoi et du comment. 

Nous pouvons des lors proposer une reponse relativement minimaliste aux questions du 
quand et du qui et, ainsi, proposer une methode de developpement avec UML. 

Notre objectif est de finir notre presentation d'UM L en presentant les principes de base 
d'une methode de developpement. Notre methode ne doit done pas etre considered 
comme une reel I e methode, applicable en milieu industriel, mais plutot comme une 
methode pedagogique. 

Pour repondre a la question du qui, nous considerons qu'il existe essentiellement deux 
personnes qui participent au developpement d'une application. Le client est la personne 
qui a besoin del 'application, etledeveloppeur la personne qui realise I 'application. Dans 
le cadre de ce cours, nous considerons que I'equipe de developpement n'est composee 
que de developpeurs. Ainsi, la redaction du cahier des charges, qui specifie tous les 
besoins, est a la charge du client, et toutes les activites de developpement relatives a 
I' analyse eta la conception sont a la charge de I'equipe de developpement. 

Pour repondre a la question du quand, nous considerons qu'il suffit de proposer un ordre 
de realisation de chacune des neuf parties du modele UML. Nous faisons le choix de 
proposer un ordre partant du cahier des charges et finissant par la production de Impli- 
cation finale. Ainsi, notre methode, qui se borne a preconiser un parcours dans la realisa- 
tion des parties du modele, est une methode dite « top-down ». Cela signifie qu'elle n'est 
uti Usable que pour la construction de nouvelles applications. 

Les gains de notre methode de developpement avec UML sont, comme nous I 'avons 
souligne tout au long dece cours, de profiter des avantages des operations real isables sur 
les modeles (generation de documentation, generation de tests, identification et correc- 
tion des dependances), de profiter des avantages des operations real isables sur le code 
(redaction du code, compilation et execution), depermettre une conception independante 
des plates-formes d' execution et minimisant les dependances entre les composants. 

La methode « UML pour le developpeur » 

Nous recapitulons dans cette section toutes les etapes de notre methode de developpe- 
ment avec UML. Soulignons que les etapes 1 a 9 concernent I ' elaboration des neuf 
parties du modele UML. 

0. Redaction du cahier des charges : 

Objectif : specifier tous les besoins du client sur I'appl ication. 

Quand : cette etape doit etre real i see avant de commencer le developpement. Elle 
n'appartientdonc pas reellementa la methode. 

Qui : leclient. 

Quoi : un document textuel recensant tous les besoins. L' ideal seraitde pouvoir iden- 
tifier chacun des besoins (en leur donnant un numero, par exemple). 
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Comment : nous ne preconisons aucune facon de rediger un cahier des charges, cela 
sortant du contexte de ce cours. 

1. Analyse (niveau besoin) - cas d'utilisation : 

Objectif: modeliser les fonctionnalites de I'application et I'environnement de 
I ' appl i cati on de maniere non ambigue. 

Quand : cette etape est la premiere de notre methode. 

Qui : I'equipededeveloppement. 

Quoi : I'uniquediagrammede cas d'utilisation du niveau d'abstraction « besoin ». 

Comment : a I'aided'une lecture soigneusedu cahier des charges, il faut, d'une part, 
identifier les fonctionnalites offertes par I'application afin de les modeliser sous 
forme de cas d'utilisation et, d'autre part, identifier les entitesexternesa I'application 
beneficiant des fonctionnalites de I'application afin de les modeliser sous forme 
d'acteurs. Rappelons que nous deconseillons I * uti I i sati on de relations d'inclusion, 
d'extension et d'heritage entre les cas d'utilisation ainsi que les relations d' heritage 
entre acteurs. 

2. Analyse (niveau besoin) - interaction : 

Objectif : modeliser les exemples de realisation des fonctionnalites de I'application 
de maniere non ambigue. 

Quand : cette etape doit etre real i see apres I'etape 1. II est possible de real iser 
I ' etape 3 en meme temps que cette etape. Analyse classe et analyse interaction 
peuvent etre faites ensemble. 

Qui : I'equipededeveloppement. 

Quoi : un diagramme de sequence, par exemple nominal de realisation d'une fonc- 
tionnal ite et un di agramme de sequence, par exemple de real isati on d' une fonctionna- 
litesoulevantuneerreur. 

Comment : a I'aide d'une lecture soigneuse du cahier des charges, il faut modeliser 
des exemples de realisation des fonctionnalites. Nous consei lions de reutiliser autant 
que possible de memes objets dans les differentes interactions. Afin d'etablir un lien 
de coherence entre les parties fonctionnelle, comportementale et structurelle, nous 
conseillons de typer tous les objets participant aux interactions, soit par des acteurs 
( parti e fonctionnelle), soit par des classes ( parti e structurelle). 

3. Analyse (niveau besoin) - classes : 

Objectif : modeliser les classes representant les donnees specifiees dans le cahier des 
charges. 

Q uand : cette etape doit etre real i see apres I'etape 1 et peut etre faite en meme temps 
que I'etape 2. A nalyse classe et analyse interaction peuvent etre faites ensemble. 

Qui : I'equipededeveloppement. 
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Quoi : autant de diagrammes de classes que necessaire afin de faciliter la lecture des 
classes ainsi que leurs relations. 

Comment : a I'aide d'une lecture soigneuse du cahier des charges, il faut modeliser 
les donnees specifiers par le cahier des charges. N ous conseillons de ne pas rendre les 
associations navigables, car les informations que nous pourrions en retirer (depen- 
dances entre objets) ne sont pas du ressort de la phase d'analyse. 

4. Conception (niveau conceptuel) - casd'utilisation : 

Objectif : modeliser les composants dela conception de I'application. 

Quand : cette etape, la quatrieme de notre methode, est la premiere de conception. 
E 1 1 e doit etre real i see apres toutes I es etapes de I a phase d' analyse. 

Qui : I'equipede developpement. 

Quoi : I iste des composants et un diagrammede casd'utilisation par composant. 

Comment: a I'aide d'une lecture soigneuse de toutes les parties de la phase 
d'analyse, il faut identifier les differents composants de I'application puis elaborer le 
diagrammede cas d' utilisation dechacun des composants. II faut ensuite specifier les 
relations de resolution entre les diagrammes de casd'utilisation des composants et le 
diagramme de cas d'utilisation de la phase d'analyse. 

5. Conception (niveau conceptuel) - interaction : 

Objectif : modeliser les exemples de realisation des fonctionnalites de chacun des 
composants de I'application. 

Quand : cette etape est la deuxieme dela phase de conception. II est possible de real i- 
ser I 'etape 7 en meme temps que cette etape. 

Qui : I'equipede developpement. 

Quoi : un diagramme de sequence, par exemple nominal de realisation d'une fonc- 
tionnalite. Un diagramme de sequence, par exemple de realisation d'une fonctionna- 
litesoulevantuneerreur. 

Comment : a partir de la definition des composants, il faut elaborer des exemples de 
realisation des fonctionnalites qu'ils proposent. Nous conseillons de reutiliser autant 
que possible de memes objets dans les differentes interactions. Afin d'etablir un lien 
de coherence entre les parties fonctionnelle, comportementale et structurelle, nous 
conseillons de typer tous les objets participant aux interactions, soit par des acteurs 
(parti e fonctionnelle), soit par des classes ( parti e structurelle). 

6. C onception (niveau conceptuel) - classes : 

Objectif: modeliser les classes des composants. Toutes les classes d'un meme 
composant doivent appartenir a un meme package. 

Quand : cette etape, la troisieme de conception de notre methode, doit etre realisee 
apres ou en meme temps que I'etape 5. 

Qui : I'equipede developpement. 
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Quoi : autant de diagrammes de classes que necessaire afin defaciliter la lecture des 
classes ainsi que leurs relations. 

Comment: a partir de la definition des composants, il faut modeliser les donnees 
qu'ils manipulent. 1 1 faut preciser les relations de dependance entre les classes (intra- 
composants et inter-composants). 

Objectif : modeliser les classes des composants en integrant les classes de la plate- 
forme d'execution. 

7. C onception (niveau physique) - classes : 

Quand : cette etape est la premiere de la phase de conception du niveau physique de 
notre methode. 

Qui : I'equipededeveloppement. 

Quoi : autant de diagrammes de classes que necessaire afin defaciliter la lecture des 
classes ainsi que leurs relations. 

Comment : a partir de la specification des composants (partie structurelle du niveau 
conceptuel), il faut identifier les classes de la plate-forme d'execution permettant la 
concretisation des composants. II faut aussi integrer les traitements associes aux 
operations sous forme de note de code. Pour finir, il faut preciser les relations 
d' abstraction avec le niveau conceptuel. 

8. Conception (niveau physique) - interaction : 

Objectif : modeliser les casde test abstraits. 

Quand : cette etape est la deuxiemede la phase de conception du niveau physique. 
Qui : I'equipededeveloppement. 

Q uoi : un diagramme de sequence de test par cas de test abstrait. 

Comment : pour chaque classe du niveau conceptuel, il faut identifier plusieurs tests 
abstraits a real iser et modeliser ces cas detest a I 'aide de diagrammes de sequence de 
test. Commeindiqueau chapitre 7, notre methode nedonneaucun moyen d' identifier 
lesbonscas detest. 

9. C onception (niveau physique) - cas d' utilisation : 

Objectif : modeliser les fonctionnalites offertes par les composants, mais au niveau 
physique. 

Quand : cette etape est la troisiemede la phase de conception du niveau physique. 
Qui : I'equipededeveloppement. 

Quoi : un diagramme de cas d'utilisation par package du niveau physique. 

Comment : en principe, tous les composants du niveau conceptuel apparaissent dans 
le niveau physique sous forme de packages. Certaines fonctionnalites des compo- 
sants du niveau conceptuel peuvent toutefois etre offertes directement par la plate- 
forme d'execution. La modelisation des fonctionnalites au niveau physique permet 
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ainsi de differencier les fonctionnal ites directement real isees par I ' appl i cation de 
eel I es offertes par la plate-forme. 

10. G eneration du code et des tests : 

Objectif : generer I e code del 'application etcelui des tests. 

Quand : cette etape est I a premiere del a phase decodage. 

Qui : I'equipede developpement. 

Quoi : le code de I ' appl icati on etcelui des tests. 

Comment : en executant les operations de generation de code et de tests. 
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Figure 10.3 

Etapes de la methode et parties du modele UML 



11. C ompilation et execution du code et des tests : 

Objectif : compiler etexecuter le code de I'application etcelui des tests. 
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Quand : cetteetapeestladeuxiemedelaphasedecodage. 
Qui : I'equipede developpement. 
Quoi : I 'executable. 

Comment : en executant les operations de compilation et d'execution fournies par la 
plate-forme d'execution. 

12. M odification del'application (correction deboguesou realisation d'evolutions) : 

Objectif : mettreajour I ' appl i cati on. 
Quand : a tout moment apres I'etape 11. 
Qui : 1'equipededeveloppement. 
Quoi : modification du modele ou du code. 

Comment : en modifiant n'importe quelle partie du modele ou en modifiant le code. 
Les operations de generation de code et de Reverse Engineering doivent etre uti I i sees 
pour assurer la synchronisation entre I e code et I e modele. 

Toutes ces etapes, apres la redaction du cahier des charges, se retrouvent dans notre 
vision schematique du modele UML d'une application, telle qu'illustree a la 
figure 10.3. 

Synthese 

Dans ce chapitre, qui clot ce cours, nous avons presente la facon dont s'articulent 
toutes les parties du modele UML d'une application lors de la realisation d'un 
developpement avec UML. 

Nous avons en particulier souligne la distinction entre les phases d'analyse et de 
conception, qui permettent respectivement de specifier le probleme pose par le client 
et la solution proposee par I'equipe de developpement, 

N ous avons en outre propose une methode pedagogique permettant de suivre un cycle 
de developpement avec UML lors de la construction d'une nouvelle application. Ce 
cycle preconise un chemin dans I 'elaboration de toutes les parties du modele UM L et 
se termine par la generation de code. 

Grace a cette methode mais surtout grace aux differentes parties du modele elaborees en 
UM L, il est possible decumuler les avantagesde la modelisation avec ceux du codage. 

Insistons a nouveau sur le fait que la methode que nous avons presentee n' utilise pas de 
maniere exhaustive toutes les possibilites d'UM L ni toutes les operations applicables 
sur les model es (simulation de modeles, verification de proprietes, etc.), qui permettent 
d'obtenir d'autres gains. Cependant, notre methode presente les parties d'un modele 
UML qui offrent le plus d'avantages en terme de developpement et qu'il est necessaire 
de maitriser pour pouvoir aller plus loin dans la modelisation des systemes. 
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Une association d'ornithologie vous confie la realisation du systeme logiciel de recueil et 
de gestion des observations realisees par ses adherents (le logiciel DataBirds). L'objectif 
est de centraliser toutes les donnees d'observation arrivant par differents canaux au sein 
d'une meme base de donnees, qui permettra ensuite d'etablir des cartes de presence 
des differentes especes sur le territoire gere par I'association. 

Les donnees a renseigner pour chaque observation sont les suivantes : 

• Nom de I'espece concernee. II y a environ trois cents especes possibles sur le 
territoire en question. Si I'observation concerne plusieurs especes, renseigner 
plusieurs observations 

• Nombre d'individus. 

• Lieu de I'observation. 

• Date de I'observation. 

• Heure de I'observation. 

• Conditions meteo lors de I'observation. 

• Nom de chaque observateur. 

Quelle que soit la fagon dont sont collectees les donnees, celles-ci sont saisies dans la 
base dans un etat dit « a valider ». Tant que les donnees ne sont pas validees par les 
salaries de I'association, des modifications peuvent etre faites sur les donnees. 

La validation des donnees se fait uniquement par les salaries de I'association qui ont le 
droit de modifier la base de DataBirds. lis doivent verifier que les donnees saisies sont 
coherentes. Plus precisement, ils doivent valider les noms des observateurs (les noms 
doivent correspondre a des noms d'adherents) et I'espece (celle-ci doit correspondre a 
une espece connue sur le territoire). 

Apres validation, une saisie se trouve soit dans I'etat dit « valide », soit dans I'etat dit 
« non valide ». Les saisies dans I'etat « non valide » sont automatiquement purgees de la 
base une fois par semaine. 

Grace aux donnees saisies et validees, I'association souhaite pouvoir etablir differents 
types de cartes de presence des differentes especes : 

• Cartes geographiques par espece presentant un cumul historique des popula- 
tions. Ce traitement peut etre demande par un adherent. 

• Cartes des observations realisees par chaque observateur. Ce traitement peut 
etre demande par un salarie uniquement. 

Ces cartes de presence des oiseaux sont generees par DataBirds et accessibles soit par 
le Web, soit par demande via un courrier electronique ou postal. 

Question 83 Effectuez la premiere etape de la methode. 

Question 84 Effectuez la deuxieme etape de la methode (niveau besoin - comporte- 
ment). 
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Question 85 Effectuez la troisieme etape de la methode. 

Question 86 Effectuez la quatrieme etape de la methode. 

Question 87 Effectuez la cinquieme etape de la methode. 

Question 88 Effectuez la sixieme etape de la methode. 

Question 89 Effectuez la septieme etape de la methode. 

Question 90 Effectuez la huitieme etape de la methode sur une seule classe. 

Question 91 Effectuez la neuvieme etape de la methode. 

Ce TD aura atteint son objectif pedagogique si et seulement si : 

• Vous savez appliquer chaque etape de la methode. 

• Vous comprenez importance des relations de coherence entre les parties du 
modele. 

• Vous etes capable de mesurer les gains offerts grace a I'elaboration du modele 
UML d'une application. 



11 



Corriges desTD 



TD1. Un curieux besoin de modelisation 

A partir du code donne en annexe, repondez aux questions suivantes. 

1. En une phrase, quels sontles roles de chacune des classes ? 

Voici la liste des classes et leur role : 

• Repertoire represents le repertoire (dans I ' appl i cati on il n'y en a qu'un). 

• Personne represents unefiched'une personne dans le repertoire. 

• Adress represents une adresse postale. 

• uiRepertoire correspond a la representation graphique d'un repertoire a partir de 
laquelle les actions sur le repertoire pourront etre appelees. 

• ui Personne correspond a la representation graphique d' unefiched'une personne a 
partir de laquelle les actions sur la fiche d'une personne pourront etre appelees. 

• uiMenuActionListener represents la classe chargee de capter tous les dies destines 
a interagir avec un repertoire et d'appeler les traitements associes. 

• La classe anonyme definie dans la classe uiPersonne est chargee de capter tous les 
dies destines a interagir avec la fiche d'une personne et d'appeler les traitements 
associes. 

• MyAssistant est la classe qui contientlafonction principale (le main) de I 'applica- 
tion. E 1 1 e cree I ' i nterface associ ee au repertoire gere par I ' appl i cation. 

2. Peut-on dire qu'il existe des classes representantdes donnees etdes classes represen- 
tantdes interfaces graphiques ? Si oui, pourquoi etquelles sontces classes ? 

Toutes les classes commencant par ui sont graphiques. Les classes uiRepertoire et 
uiPersonne represented les interfaces graphiques permettant la gestion des reper- 



124 



UML pour les developpeurs 



toires et des personnes, tandis que la classe uiMenuActi on Listener est en charge de la 
gestion des actions sur les interfaces et de la realisation des fonctionnalites asso- 
cieesaces actions. 

Les classes Repertoire, Personne et Adresse represented les donnees manipulees par 
I 'application. 

La classe MyAssistant ne represente ni des donnees ni des interfaces graphiques ; 
elleserta « lancer » I 'application. 

3. Est-il possible que le numero de telephone d'une personne soit +33 1 44 27 00 00 ? 

Oui, parcequelespropheteStelephoneMaison, telephonePortable ettelephoneBureau de 

la classe Personne sont de type string et qu'aucune verification n'est faite sur sa valeur. 

4. Est-il possible que I'adresse e-mail d'une personne soit 
« je_ne_veux_pas_donner_mon_email » ? 

Oui, parcequela proprietemaii dela classe Personne (qui correspond a I'adresse e- 
mail) est de type string et qu'aucune verification n'est faite sur sa valeur. 

5. Quelles sont les fonctionnalites proposees par les menus graphiques de cette 
application ? 

II faut regarder les classes gerant les interfaces graphiques. El les creent, dans notre 
cas, soit des menus deroulants, soit des boutons de soumission. 

La classe ui Repertoire cree trois menus deroulants : Fichier, Organisation et Aide. 
Les fonctionnalites sont les elements de chacun de ces trois menus. M is a part le 
nom de ces fonctionnalites, le code de cette classe ne permet pas de connattre le 
service realise par chacune de ces fonctionnalites. 

Voici chacun des menus avec les elements qu'il contient : 

• M enu Fichier : 

- Nouveau 

- Ouvrir 

- Enregistrer 

- Enregistrer Sous 

• M enu Organisation : 

- Ajouter Nouvelle Personne 

- Rechercher Personnel s) 

• Menu Aide: 

- A Propos 

La classe uiPersonne est I' interface graphique associee a une personne. Elle cree 
deux boutons de soumission : Save et Cancel. Comme pour les menus deroulants, 
seul le nom des boutons peut nous renseigner sur la fonctionnalite associee. 

6. Quelles sont les fonctionnalites reellement realisees par cette application ? 

Pour avoi r la reponse, i I faut regarder dans I e code associ e aux cl asses de gesti on des 
interfaces. 
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Pour un repertoire, il s'agit de la classe uiMenuActionListener, dans le code de 
laquelle nous constatons que seules les foncti onnal ites Ajouter Nouvelle Personne 
et Nouveau sont real i sees. Les autres foncti onnal ites ne font qu'afficher un 
message. 

Pour une personne, il n'y a pas de classe nommee associee a la gestion de I' inter- 
face. II faut regarder, dans lecodedela classe ui Personne, lecodeassociea la classe 
anonymeassurant la gestion de I'interface. Nous constatons alors que les foncti on- 
nal ites Save et Cancel sont real i sees. 

7. Est-il possible de sauvegarder un repertoire dans un fichier ? 

C'est a priori possible puisque I 'option Enregistrer Sous du menu Fichier le laisse 
supposer. Cependant, lecodenous informequecettefonctionnaliten'estpas encore 
real i see. 

8. Si vous aviez a rediger un document decrivant tout ce que vous savez sur cette applica- 
tion afin qu'il puisse etre lu par un developpeur qui veut reutiliser cette application et un 
chef de projetqui souhaite savoirs'il peutintegrer cette application, quelles devraientetre 
les caracteristiques de votre document? 

Le document doit contenir toutes les informations relatives aux differentes vues 
(diversite), aux differents niveaux d'abstraction sans oublier les relations de cohe- 
rence reliant tous ces elements. 

Plus precisement, a parti r du code de I 'application, il est possible (mais pas simple) 
de rediger une documentation : 

• des services offerts par I' application (utile au developpeur etau chef de projet) ; 

• de conception de I ' appl ication (utile au developpeur) ; 

• d' architecture del 'appl ication (utile au developpeur) ; 

• des logiciels necessaires a I 'utilisation de I 'appl ication (utile au developpeur etau 
chef de projet). 

9. Redigez un document presentant I'application MyAssi stant. 

L'application MyAssistant permet de gerer des repertoires. Un repertoire contient 
des informations relatives a des personnes. Pour chaque personne, il est possiblede 
stacker un nom, un prenom, un numero de telephone du domicile, un numero de 
telephonedu travail, un numero de telephone deportable, un numero defax, un titre, 
une societe, une adresse et une adresse e-mail. 

10. Redigez un document decrivant les fonctionnalites de l'application MyAssistant. 

Attention : I' interpretation des fonctionnalites non real i sees par le codejava fourni 
se fait en fonction du nom du menu associeet par similitude a ce qui se fait dans la 
majori fides applications. 

Les fonctionnalites offertes par l'application sont de deux sortes. Les fonctionna- 
lites sur un repertoire et les fonctionnalites sur une personne. 



126 



UML pourles developpeurs 



L es fonctionnal ites de gestion d'un repertoire sont les suivantes : 

• Creer un nouveau repertoire (menu Fichier/Nouveau). 

• Ouvrirun repertoire dej a existant (menu Fichier/Ouvrir). 

• Enregistrer un repertoire, c'est-a-dire enregistrer toutes les informations sur les 
personnes identifiers dans le repertoire (menu F ichier/E nregistrer). L'enregistre- 
ment se fait dans le fichier d'origine du repertoire s'il s'agit du repertoire deja 
existant. Sinon, I'enregistrement se fait dans un nouveau fichier que I * uti I isateur 
aura a identifier. 

• Enregistrer un repertoire dans un autre fichier que le fichier d'origine, s'il existe 
(menu F ichier/E nregistrer Sous). 

• Ajouter une nouvelle personne dans le repertoire ouvert (menu Organisation/ 
Ajouter Nouvelle Personne). Cette fonctionnalite propose a I ' uti I isateur de saisir 
les informations correspondant a une nouvelle personne. 

• Rechercher une personne (menu Organisation/Rechercher Personne). Cette fonc- 
tionnalite permet de rechercher la total ite des informations sur une personne en 
n'en saisissantqu'unepartie(nom, numero de telephone, unepartiedu nom, etc.). 
1 1 faudrait avoir le cahier des charges ou un code complet pour savoi r exactement 
a partir de quoi la recherche peut etrefaite. 

• A fficher I'aide sur I ' appl i cati on (menu Aide/A Propos). Cette fonctionnalite 
permet a I 'uti I isateur d'acceder a I'aide disponible sur I 'application. La aussi, il 
n'y a aucune information sur la forme de cette aide. 

Les fonctionnal ites de gestion d'une personne sont les suivantes : 

• Sauvegarder les informations saisies pour une personne (bouton Save de I' inter- 
face graphique associee a une personne). Attention : pour ajouter effectivement 
une personne a un repertoire, il faut enregistrer le repertoire. Se contenter de 
sauvegarder les informations relatives a la personne n'est pas suffisant. 

• Annuler les modifications faites sur les informations d'une personne (bouton 
Cancel de I' interface graphique associee a une personne). Cette fonctionnalite 
annule toutes les modifications faites depuis la derniere sauvegarde des informa- 
tions. 

11. Redigez un document decrivant I'architecture generale de I'application MyAssistant. 
U ne solution (qui n'est pas unique) consiste a considerer un composant pour : 

• I' interface graphique; 

• la base de donnees stockant les informations sur les personnes et les repertoires ; 

• I'interface avec la base de donnees ; 

• la realisation de la « logique » des fonctionnal ites de I'application. 

La figure 1 illustre les liens de communication qui existent entre les differents 
composants. II est important dedonner la legendedu schema. 



Corriges des TD 



Interface 
graphique 



Logique 
Fonctionnalites 



Composant graphique 



Composant logique 



[ ] Composant base de donnees 



Communication 



Figure 1 

Architecture general e de M yA ssistant 



Chapitre 11 



Interface base de donnees 



Base de donnees des 
personnes et repertoires 



TD2. Diagrammes de classes 

12. Definissez la classe UML representantun etudiant, caracterise, entre autres, parun iden- 
tifiant, un nom, un prenom etune date de naissance. 

Voici une solution ne prenant en compteque les proprietes d'un etudiant nominees 
dans la question. 

La classe se nomme Etudiant, et el I e possede les quatre proprietes suivantes, repre- 
sentees a la figure 2 : 

• id, de type Integer, qui represente I' identifiant de I'etudiant. 

• nom, de type String, qui represente I e nom de I'etudiant. 

• prenom, de type String, qui represente I e prenom de I'etudiant. 

• dateNaissance, de type Stri ng, qui represente I a date de naissance del 'etudiant. 

Figure 2 
Classe Etudiant 



Etudiant 



id:integer 
nom:string 
prenom:string 
dateNaissance:string 
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Cette definition n'impose aucune regie sur le format de saisie de la date de nais- 
sance. 

13. Definissez la classe UML representant un enseignant, caracterise, entre autres, par un 
identifiant, un nom, un prenom et une date de naissance. 

La reponse est similaire a celle de la question precedents si cen'estque lenom de 
la classe est maintenant Enseignant, comme I'illustre la figure 3. 



Figure 3 

Classe Enseignant 



Enseignant 



id :integer 
nomistring 
prenomstring 
dateNaissance:string 



14. Definissez la classe UML representant un cours, caracterise par un identifiant, un nom, le 
nombre d'heures de cours magistral, le nombre d'heures de travaux diriges etun nombre 
d'heures de travaux pratiques que doitsuivre un etudiant. 

La question etant exhaustive sur les proprietes de la classe, i I n'y a pas dechoix. Les 
seules I iberf.es sont sur les types des proprietes. Voici une solution possible. 

La classe se nomme cours, et el I e possede les cinq proprietes suivantes (voir 
figure 4) : 

• id, de type integer, qui represente I' identifiant du cours. 

• nom, de type string, qui represente le nom du cours. 

• nbHeuresCours, de type i nteger, qui represente I e nombre d'heures decours magis- 
tral. 

• nbHeuresTD, de type integer, qui represente le nombre d'heures de travaux diriges. 

• nbHeuresTP, de type integer, qui represente le nombre d'heures de travaux pratiques. 



Figure 4' 

Classe Cours 



Cours 

id:integer 
nom:string 

nbHeureCours:integer 

nbHeureTD:integer 

nbHeureTP:integer 



15. Definissez les associations qui peuventexister entre un enseignant etun cours. 

La question n'est pas assez precise pour qu'une seule solution soit possible. Toutes 
les associations realistes sont possibles. 

Nous considerons deux associations entre ces classes. La relation Responsabiiite 
permet d'associer a un cours I'enseignant qui en est responsable et d'associer a un 
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enseignant I' ensemble des cours qu'il gere (un enseignant pouvant ne gerer aucun 
cours). La relation Dispenser permetd'associer a un cours I'ensembledesenseignants 
qui y participent (nous parlons alors des intervenants d'un cours), cet ensemble ne 
devant pasetrevide. Cette relation permetaussi d'associera un enseignant rensemble 
des cours qu'il dispense, ensemble qui lui non plus nepeutetre vide. 

Les associations representees a la figure 5 prennenten comptetoutes les contraintes 
precedentes. 



Cours 


Dispenser 


Enseignant 


id :integer 
nom:string 

nbHeureCours:integer 

nbHeureTD:integer 

nbHeureTP:integer 


coursDispense intervenant 
coursGere Responsabilite responsable 


id:integer 

nom:string 

prenom:string 

prenom:string 

dateNaissance:string 


* 1 







Figure 5 

Associations entre les classes Cours et Enseignant 



Nous ne nous sommes pas interesses a la navigabilite des associations. Cependant, 
meme si les associations ne sont pas navi gables, des liens peuvent etre crees entre 
objets instances des classes. Dans ce cas, les objets seront lies mais n'auront pas 
connaissance des liens. II ne sera, par exemple, pas possible de passer par un cours 
pour acceder a son responsable. L a facon dont les choses seront reellement real i sees 
depend de la plate-forme d' execution utilisee. 

16. Definissez la classe UML representantun groupe d'etudiants en utilisa nt les associations. 

II n' est pas possibled'utiliser une association groupe de la classe Etudiant vers el I e- 
meme. Cette association permettrait de relier des etudiants entre eux mais ne 
permettrait pas d' identifier les differents groupes. II est done necessaire d'avoir une 
representation nous permettantd' identifier les groupes. 

Nous ajoutons done une classe Groupe, que nous associons a la classe Etudiant. 
L'association entre les deux classes se nomme Groupement. Nous considerons qu'un 
etudiant peut appartenira pi usieurs groupes, voire aucun, qu'un groupe contient au 
moins deux membres mais n'a pas de limite superieure sur le nombre de ses 
membres. L'association est graphiquement representee a la figure 6. 



Groupe 



Figure 6 

Classe Groupe 



groupe 



Groupement 



membre 



Etudiant 



id:integer 
nom:string 
prenom:string 
dateNaissance:string 
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17. Definissez I'association possible entre un groupe d'etudiants etun cours. 

Nous nommons I'association GroupeDeCours. Nous considerons que les groupes sont 
redefinis pour chaque cours et qu'il faut au moins un groupe pour qu'un cours ait 
lieu. En consequence, a un groupe nous n'associons qu'un seul cours, et a un cours 
nous associons un a plusieurs groupes. 

La figure 7 represents graphiquement I'association GroupeDeCours. 



Figure 7 

Association 
G roupeDeCours 



Groupe 



groupeExistant 



GroupeDeCours 



cours 



Cours 



id :integer 
nom:string 

nbHeureCours:integer 

nbHeureTD:integer 

nbHeureTP:integer 



18. Pensez-vous qu'il soit possible de definirun lien d'heritage entre les classes UML repre- 
sentant respectivement les etudiants et les enseignants ? 

Pour pouvoir definir un lien d'heritage entre deux classes, i I faut que I'ensembledes 
objets instances d'une des deux classes soit inclus dans I 'ensemble des objets 
instances de I 'autre. Ce n'est pas le cas ici, puisque tous les etudiants ne sont pas des 
enseignants et que tous les enseignants ne sont pas des etudiants. Le fait que des 
enseignants puissent aussi etudier certains cours ne peut se representor avec un lien 
d'heritage entre classes. 

Le lien entre ces deux classes d' objets est qu'il s partagent certaines proprietes 
propres a une personne. Si nous voulons faire apparaitre ce lien, il nous faut intro- 
duire une classe Personne, comme le montre la figure 8. Les classes Etudiant et 
Ensei gnant heritent alors de la classe Per sonne. 

19. Pensez-vous qu'il soit possible de definirun lien d'heritage entre les classes UML repre- 
sentant respectivement les etudiants et les groupes d'etudiants ? 

Ce n'est pas possible pour la meme raison que precedemment. Les classes Etudiant 
et Groupe represented des ensembles d'objets differents ne presentant aucune rela- 
tion d'inclusion. Les groupes ne sont pas des etudiants (et inversement). Par contre, 
les groupes sont composes d'etudiants, et les etudiants appartiennent a des groupes, 
ce qui est represente par I'association Groupement. 
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Figure 8 

H eritage 
pour les classes 
Etudiant 
et Enseignant 



Personne 



id:integer 

nom:string 

prenom:string 

prenom:string 

dateNaissance:string 

A 



Etudiant 

id:integer 
nom:string 
prenom:string 
dateNaissance:string 



Enseignant 

id:integer 
nom:string 
prenom:string 
prenom:string 
dateN a issa nee string 



20. On nomme coursDel_Etudiant( ) I'operation permettant d'obtenir I'ensemble des cours 
suivis par un etudiant. Positionnez cette operation dans une classe, puis precisez les 
parametres de cette operation, ainsi que les modifications a apporter aux associations 
prealablement identifies pour que votre solution soit realisable. 

II semble assez naturel de mettre cette operation dans la classe Etudiant, car les 
associations permettent, a parti r d'un etudiant, de retrouver I'ensemble des cours 
auxquels il assiste. Dans ce cas, les parametres d' entree (in) sont inexistants, et 
I'operation s' applique sur I'objet courant (I 'etudiant). Letype du retour de I'opera- 
tion estun ensemble, eventuellement vide, de cours de type cours. 

Pour mettre en place cette solution, il est indispensable de pouvoir acceder aux 
groupes auxquels un etudiant appartient et, depuis ces groupes, de pouvoir acceder 
au cours associe a chacun d'eux. II faut alors mettre les navigabilites adequates sur 
I'association Groupement de la classe Etudiant vers la classe Groupe et sur I'associa- 

tion GroupeDeCours de la Classe Groupe vers la ClaSSe Cours. 

Si nous acceptons d'aj outer des associations par rapport a ce qui a deja ete fait, une 
solution pour mettre en place notre solution est de definir une association entre les 
classes Etudiant et Cours permettant d'associer directement un etudiant aux cours 
qu'il suit et un cours aux etudiants qui le suivent. Cette association doit etre navi- 
gable de la classe Etudiant vers la classe cours. 

21. Nous nommons coursDeLEnseignanto I'operation permettant d'obtenir I'ensemble des 
cours dans lesquels intervient un enseignant. Positionnez cette operation dans une 
classe, puis precisez les parametres de cette operation, ainsi que les modifications a 
apporter aux associations prealablement identifies afin que votre solution soit realisable. 
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II semble assez naturel de mettre cette operation dans la classe Enseignant, car les 
associations permettent, a parti r d'un enseignant, de retrouver I'ensembledes cours 
dans lesquelsil intervient. Danscecas, les parametresd' entree (in) sontinexistants, 
et I' operation s'applique sur I'objet courant (I'enseignant). Le type du retour de 
I' operation estun ensemble, eventuellement vide, de cours detypecours. 

Pour mettre en place cette solution, il est indispensable de pouvoir acceder aux 
cours que dispense un enseignant. II fautdonc mettreles navigabi I ites adequatessur 

I'aSSOCiation Dispenser de la ClaSSe Enseignant vers la ClaSSe Cours. 



22. Expliquez le diagramme de classes represente a la figure 9. 



Figure 9 

Diagramme de 
classes du package 
planning 



planning 



Planning 



occupe 



Salle 



numercdnteger 



Semaine 



numero:integer 



calculerC reneauxLibresO 




joursOuvrables 



J ours 



date:string 
nom:string 



ferie() 

calculerC reneauxLibresO 

7K 

jours 



C reneau 



heureDebutstring 
heureF in:string 



Le diagramme de classes du package planning represente I'occupation d'un 
ensembl e de sal I es (eventuel I ement vi de) . 
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Ce package COntient Cinq Classes, Planning, Salle, Semaine, Jours et Creneau. 

La classe creneau contient les informations d'un creneau horaire determine par une 
heure de debut et une heure de fin. Un creneau est associe a un jour. II permet 
d' identifier un creneau d'occupation d'une salle un jour donne. 

La classe Jours contient les informations sur I'ensemble de creneaux occupes dece 
jour. Un jour est determine par une date et un nom (jour dans la semaine). II est 
possible de savoir si un jour correspond a un jour ferie et quels sont ses creneaux 
libres. Cette derni ere operation est possible grace a I' association navigable entre les 
classes Jours et creneau, qui permet d'avoir la liste des creneaux occupes pour un 
jour donne. Cette classe permet done d' identifier les creneaux d'occupation d'une 
salle pour un jour donne. 

La classe semaine contient les informations sur les creneaux composant I'ensemble 
des jours de la semaine. U ne semaine est representee par son numero. L' association 
navigable de la classe semaine vers la classe Jours permet d'avoir accesaux informa- 
ti ons sur I es creneaux occupes de I ' ensemble des j ours de I a semai ne. C ette associa- 
tion est necessaire pour la realisation de I'operation caicuiercreneauxubreso, qui 
permet d'identifier les creneaux libres pour une semaine donnee. Nous avons en 
pi us I ' i nformati on qu' une semai ne est composee de ci nq j ours ouvrabl es exactement. 
Cette classe permet done d'identifier les creneaux d'occupation d'une salle pour 
une semaine donnee. 

La classe Saiie contient les informations sur I 'occupation d'une salle. Une salle est 
representee par son numero. L'association navigable entre I a classe Sal 1 e et la classe 
semaine permet derecuperer I 'ensemble des informations sur I 'occupation del a salle 
pour un nombre quelconque de semaines. Une semaine est associee a une seule 
salle. Une meme semaine (en terme de numero) existera en autant d'exempl aires 
que de sal les occupees cette meme semaine. Chacune de ces semaines represente 
I'occupation d'une salle en particulier. Cette classe permet done d'identifier les 
creneaux d'occupation d'une salle pour un ensemble de semaines. 

La classe Planning conti ent les informations sur I'occupation d'un ensemble de 
sal les (eventuellementvide). E He ne contient aucune propriete. Grace a une associa- 
tion vers la classe saiie, il est possible d'acceder a I'ensemble des sal les et de recu- 
perer les informations sur leur occupation. 

23. Positionnez tOUtes VOS Classes (Etudiant, Enseignant, Cours, GroupeEtudiant) dans un 

package nomme personnel. 

La solution est donnee par la figure 10. 

24. Liez vos classes afin de faire en sorte qu'un creneau soit lie a un cours ! 

II faut mettre une association entre la classe cours du package personnel et la classe 
creneau du package planning. Si nous souhaitons pourvoir identifier le cours ayant 
lieu dans une salle pour un jour et un creneau donnes, il faut que cette association 
soit navigable de la classe creneau vers la classe cours et que le package planning 
importe I e package personnel. C'est ce qu'illustre la figure 11. 
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Figure 11 
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TD3. Reverse Engineering 



Les operations de Reverse Engineering presentees dans ce TD portent sur le code Java 
de I'application MyAssistant donne au TD1. Nous appliquons les regies de correspon- 
dance Java vers UML decrites au chapitre 3. 

25. Effectuez le Reverse Engineering de la classe Adresse. 

Les informations se trouvent dans le code de la classe Adresse : 

• Regie 1 : a la classe Java Adresse doit correspondre une classe UM L Adresse. 

• Regie 3 : a tout attri but de la classe Java Adresse doit correspondre une propriete 
de meme nom dans la classe UM L associee. Le type Java detous les attri buts de 
la classe Adresse etant string, le type des proprietes associees sera le type UML 

string. II y a Cinq proprietes : pays, region, codePostal, ville et rue. 

• Regie 4 : a to ute operation de la classe Java Adresse doit correspondre une operation 
de meme nom appartenant a la classe UM L correspondante. La classe Java Adresse 
contient deux operations. II s'agit des operations de lecture de la valeur d'un attri but 
(public typeAttribut getNomAttribut( )) et des operations d' affectation d'une valeur 

a Un attri but (public void setNomAttribut(typeAttribut nomParametre)). NOUS 

retrouvons done les operations equivalentes dans la classe UM L. Les operations de 
lecture d'un attri but sont traduites par une operation ayant un parametre de sortie du 
type de I ' attri but et aucun parametre d'entree (getNomAttribuu ) :typeAttribut). Les 
operations d' affectation d'une valeur a un attri but sont traduites par une operation 
avec un parametre d'entree du meme type que I 'attri but et aucun parametre de sortie 

(setNomAttributdn nomParametre: typeAttribut). LeS operations J ava etant tOUteS 

publiques, les operations UM L correspondantes le seronttoutes aussi. 

Seules ces trois regies s'appliquent au Reverse Engineering de la classe Adresse. II 
ne faut pas oublier d'attacher a chacune des operations une note contenant le code 
de traitement de I'operation J ava associee (regie 9). 

Dans la representation graphique de la classe qui est donnee a la figure 12, les 
operati ons sont precedees d' un +, et leur parametres sont masques. N ous avons aussi 
choi si de masquer les notes attachees aux operations. 

Figure 12 

Classe Adresse 



Adresse 



pays:string 
region:string 
codePostakstring 
ville :string 
rue:string 



+getCodePostal() 

+setCodePostal() 

+getPays() 

+setPays() 

+getRegion() 

+setRegion() 

+getRue() 

+setRue() 

+getVille() 

+setVille() 
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26. Effectuez le Reverse Engineering de la classe Personne. 

Les informations se trouvent dans lecodede la classe Personne. La traduction de la 
majori tides attributs et operations J ava ne pose pas de probleme parti culier et sefait 
defagon similairea ce que nous avons fait pour la classe Adresse. 

Pour les operations, la seule difference vient de I' operation tostringo, qui ne 
modifie pas un attri but ni ne retourne sa valeur. Elle retourne en fait une chatne de 
caracteres composee de la valeur de deux attributs. Sa traduction ne pose pas de 
probleme particulier : nous ajoutons a la classe Personne du modele UM L I 'opera- 
tion +tostring():string. II ne faut pas oublier d'attacher a chacune des operations 
une note contenant I e code de traitement de I 'operation J ava associee. 

Pour les attributs, la seule difference vient de I ' attri but adresse de type Adresse. 
Nous appliquons alors la regie 3 modifiee, qui nous dit de ne pas creer de propriete 
Adresse mais de creer une association navigable entre la classe Personne et la classe 
Adresse. L e nom de rol e associ e a I a cl asse Adresse est I e meme que eel ui de I ' attri but 
Java. II s'agitdonc ici de adresse. Une personne ayant une seule adresse, nouspreci- 
sons sur I'association UML qu'a une Personne est associee 0 a 1 adresse (nous 
acceptons d'avoir une propriete dont la valeur n'est pas definie). 

La figure 13 represents I'association entre les classes Personne et Adresse. 



27. Effectuez le Reverse Engineering de la classe Repertoire. 

Les informations se trouvent dans le code de la classe Repertoire. Cette classe ne 
possede qu'un attri but de type ArrayList, qui est une classejava. Comme pour la 
question precedents, nous appliquons la regie 3 modifiee. Nous necreons done pas 
de propriete dans la classe Repertoi re mais creons une classe UML ArrayList et une 
association navigable entre les classes UM L Repertoire et ArrayList. Lenom de role 
associe a la classe ArrayList est le nom de I ' attri but J ava, ici personnes, et la multi- 
pi i ci te associ ee a cette c I asse est 0. . 1 . 

La classe J ava contient cinq operations, dont nous retrouvons les operations corres- 
pondantes dans la classe UML Repertoire. II ne faut pas oublier d'ajouter pour 
chacune d'elles une note contenant le codej ava. 

Voici la listedeces operations: 



+ajouterPersonne(in p:Personne) 
+supprimerPersonne(in p: Personne) 
+rechercherPersonnesParNome(in nom: string) : 
+lister Personnes ( ) : Personnes [*] 
+Repertoi re( ) : Personnes[*] 



Les deux dernieres operations retournent un tableau de personnes dont la tail le n'est 
pas precisee. 



Figure 13 

Association entre 
les classes Personne 
et Adresse 



Personne 



adresse 



0..1 



^ Adresse 
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L a figure 14 represente I 'association entre les classes Repertoire etArrayList. 



Figure 14 

Association 
entre les classes 
Repertoire 
etArrayList 



personnes 



Repertoire 




Array List 


> 



0..1 



28. Pourquoi n'y a-t-il pas d'association entre la classe Repertoire et la classe Personne alors 
qu'un repertoire contientdes personnes ? 

La declaration des attributs de la classe J ava Repertoi re ne mentionne aucun attri but 
de type Personne, mais mentionne un attri but de type ArrayList. Le lien entre le 
repertoire et les personnes se fait grace au lien qui existe entre les classes Java 
ArrayList et Personne. Ces classes sont liees par la classe J ava object. II existe une 
association entre les classesjava ArrayList et object parceque, d'unepart, un objet 
de type ArrayList est compose d'un tableau d'elements de type object et que, 
d'autre part, toute classe J ava herite de la classe object. La classe Personne herite 
done de la classe object. 

Ces relations font qu'un repertoire peut contenir un tableau de personnes. Cette 
relation n'est pas refletee par lemodeleUM L, car il necontient pas la classe objet. 
Ajouter cette classe au modele UML necessiterait d'etablir les liens entre el le et 
toutes les autres classes, ce qui n'est guere envisageable. 

29. Comment modifier les regies du Reverse Engineering pourfaire en sorte qu'une associa- 
tion SOit etablie entre la Classe Repertoi re et la Classe Personne ? 

Dans notre cas, nous pouvons etablir cette association, puisque I 'attri but de type 

ArrayList de la Classe Repertoire ne COntient que des elements de type Personne. Cet 

attri but peut done etre represente par une association entre les classes Repertoire et 
Personne. Cela n'est cependant pas toujours possible, car un objet de type ArrayList 
contientdes elements de type object. Puisque toutes les classes heritent de la classe 
object, un objet de type ArrayList peut theoriquement contenir des elements de 
n'importe quel type, et ils ne sont pas tous obligatoirement de meme type. L' asso- 
ciation entre la classe ayant une propriete de type ArrayList et la classe representant 
le type des objets contenus dans le tableau dynamique (ArrayList) n'est done pas 
toujours possible. 

Nous dirons done que si, dans J ava, un attri but d' une classe a est de type ArrayList 
et que le code montre que tous les objets ajoutes au tableau dynamique sont de 
meme type (represente par une classe b), nous pouvons mettre une association de la 
classe a vers la classe b. 

Attention : les associations peuventsededuire des types des attributs, mais non des 
types des parametres des operations de la classe. Si une operation de la classe a a un 
parametre de type b, rien ne dit que ce parametre est une information accessible 
directement depuis la classe a. II peut etre le resultat d'une operation appelee par la 
classe a. II n'y a done pas lieu d'associer les classes a et b. 
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30. Effectuez le Reverse Engineering de la classe uiPersonne. 

Les informations se trouvent dans le code de la classe uiPersonne. Nous constatons 
tout d'abord que la classe uiPersonne herite de la classe jPanei, relation qui doit 
apparattre dans le modele UM L. Nous ajoutons done une classe JPanei dont herite 
la classe uiPersonne. La classe uiPersonne contient onze attributs, un de type 
Personne et les dix autres de type JtextFieid. L'attribut de type Personne est repre- 
sent par une association navigable entre la classe uiPersonne et la classe Personne. 
Le nom de role associe a la classe Personne est personne, et la multi pi i cite associee 
estO.,1. 

Pour les autres attributs, nous ajoutons au modele la classe jFextFieid, et nous 
creons une association navigable entre la classe uiPersonne et la classe JTextFieid 
pour chacun des attributs. Pour chacune de ces associations, le role associe a la 
classe JTextFieid correspond au nom de l'attribut Java, etla multi pi i cite associee est 
0..1. 

Nous ajoutons a la classe UM L les cinq operations suivantes, auxquelles nous ajou- 
tons en note le code J ava associe : 

+UIPersonne( ) 

+UIPersonne(in p:Personne) 
+get Personne ( ) : Personne 
+setPersonne(in personne: Personne) 
+init( ) 

1 1 est i mportant de noter que les regies de Reverse E ngi neering que nous avons defi- 
nies ne permettent pas de prendre en consideration la classe anonyme creee par 
I 'operation init. 

La figure 15 represents les liens (heritage ou association) entre la classe uiPersonne 

et les Classes JPanei , Personne et JTextFieid. 

31. Comment introduire les classes J ava dans le modele UML ? A quoi cela sert-il ? 

1 1 f aut appl i quer une operati on de R everse E ngi neeri ng sur I e code de I 'A PI J ava qui 
se trouve dans lefichier rt.jar. 1 1 faut done di sposer des sources de I ' A P I et avoi r des 
regies de Reverse Engineering s' appl i quant a cetype de source. II n'est pasforce- 
ment judicieux de traiter de la meme maniere le Reverse Engineering d'une appli- 
cation complete et eel ui d'une archive (fichier .jar en J ava) regroupantun ensemble 
de classes et les ressources associees. 

E n fai t, i I n' est pas i nteressant d' i ntrodui re dans I e model e U M L toutes I es i nforma- 
tions qu'il est possible d'obtenir sur I'API Java (telles que les liens entre les classes 
de I'API). L'objectif est uniquement d'introduire les classes de I'API apparaissant 
directement dans le code afin de pouvoir les referencer et les lier aux classes de 
I' application. Ces liens sont indispensables pour pouvoir real iser la generation de 
code. 
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Figure 15 

Associations entre U I Personne et J TextField 



32. Est-il plus facile de comprendre une application apres en avoir effectue le Reverse 
Engineering ? 

L'operation de Reverse Engineering nefacilite pas la comprehension d' une applica- 
tion. II nes'agitquede representor graphiquementlecode. Les diagrammes obtenus 
ne sont que la vue structurelle au niveau d'abstraction le plus bas de I'appl ication. 
Pour comprendre facilement I ' appl i cati on, il faut produire les diagrammes associes 
a chacune des vues pour chacun des niveaux d'abstraction. 

33. Les informations obtenues apres Reverse Engineering sont-elles plus abstraites que le 
code J ava ? 

Non, les informations sont equivalentes. Le model eobtenu apres Reverse Enginee- 
ring ne represente que les informations contenues dans I e code. La preuveen est que 
notre model e contient des classes J ava. 
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34. Le modele obtenu par Reverse Engineering contient-il plus de dive rsite que le code ? 

Si, comme nous le preconisons, le Reverse Engineering produit plusieurs 
diagrammesde classes, le modele obtenu offre un peu plus de diversite que lecode. 
Cependant, il nous permetuniquementd'obtenir la vuestructurelle del 'application. 

Une analyse plus poussee du code pourrait nous permettre d'obtenir des informations 
sur le comportement et les fonctionnalites de I'application. M ais la mise en place de 
cette analyse rendrait I'operation de Reverse Engineering beaucoup plus delicate, car 
I'identification des nouveaux diagrammes a produire et des classes a faire apparattre 
dans ces diagrammes n'est pas evidente. II est difficile d'automatiser ces operations, 
dont le resultat depend beaucoup del'experiencede eel ui qui les realise. Les regies que 
nous donnons pour le Reverse Engineering sont facilement automati sables et doivent 
done toujours produire le meme resultat pour un code donne. 

35. Si vous aviez un modele UML et le code Java correspondant, comment pourriez-vous 
savoirsi le modele UML a ete construita partird'un Reverse Engineering ? 

Comme nous venons de le voir, I'application de nos regies de Reverse Engineering 
produit des resultats deterministes. Pour un code donne, pour un ensemble de regies 
donne, le resultat du Reverse Engineering sera toujours le meme, alors qu'un etre 
humain ne ferait pas toujours les memes choix etajusteraitses decisions en fonction 
de divers facteurs. Dansnotrecas, nous pouvons dire que, si le modele contient, par 
exemple, des liens avec la classe Array List ou si toutes les associations sont naviga- 
bles a I'unede leurs extremites et que les multi pi icit.es soient 0..1, alors le modele a 
ete obtenu par Reverse Engineering. 

Defacon general e, plus les mecanismes de Reverse Engineering sont « simples » a 
mettre en oeuvre, plus ils sont identifiables, puisqu'ils n'autorisent pas de variete 
dans les traitements realises. Cependant, il est parfois possible de parametrer 
I ' operati on de R everse E ngi neeri ng et done de di versifi er I es traitements en f oncti on 
des particularites du code considere (application complete, A PI Java, etc.). 



TD4. Retroconception et patrons de conception 

La figure 1 6 represente les relations entre les classes Synchroni sateur et Cal cul ateur. Un 
calculateur permet d'effectuer des calculs. Etant donne que n'importe qui peut demander 
a un calculateur d'effectuer des calculs, la classe Synchroni sateur a ete construite pour 
reguler les calculs. 

Les personnes qui souhaitent demander la realisation d'un calcul doivent passer par le 
synchronisateur (via I'operation calculerO). Celui-ci distribue les calculs aux differents 
calculateurs avec lesquels il est lie (e'est lui qui appelle I'operation calculerO sur les 
calculateurs). Un calculateur connaTt le synchronisateur auquel il est relie grace a la 
propriete sync de type Synchronisateur. Sa valeur doit etre determines lors de la creation 
des objets de type Cal cul ateur. 



Figure 16 
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36. Exprimez en les justifiant les dependances entre les classes Synchroni sateur et Cai cui ateur. 

L'association navigable de la classe synchronisateur vers la classe caicuiateur 
etablit une dependance de la classe synchronisateur vers la classe calculates. La 
propriete sync de type synchronisateur de la classe caicuiateur etablit une depen- 
dance de la ClaSSe Caicuiateur vers la ClaSSe Synchronisateur. 

37. Nous souhaitons que les classes Synchronisateur et Caicuiateur soient dans deux 
packages differents. Proposez une solution. 

Comme nous venons de le voir a la question precedente, il y a un cycle de depen- 
dances entre les classes caicuiateur et synchronisateur. Nous ne pouvons nous 
contenter de les mettre dans deux packages differents, car il faudrait alors etablir 
une dependance mutuelle entre ces deux packages. Nous devons done « deporter » 
une des causes du cycle de dependances hors de sa classe d'origine. 

N ous ne considerons que la classe cai cui ateur et choisissons de deporter I 'operation 
caicuiero de la classe caicuiateur, qui est a I'originede la dependance de la classe 
Synchronisateur vers la classe Caicuiateur. L'association est la pour permettre a un 
synchronisateur d' identifier les calculateurs qui dependent de lui et de pouvoir 
appeler leur operation caicuiero. N ous creons done une classe cai cui ateurSup, dont 
herite la classe caicuiateur etqui contient I 'operation caicuiero. L'association est 
de la sorte el le aussi deportee de la classe cai cui ateur vers la classe cai cui ateurSup. 

N ous pouvons mettre dans un meme package les cl asses synchroni sateur et cai cui a- 
teurSup et dans un autre la classe caicuiateur. Les dependances sont alors internesa 

Un package (association entre les Classes Synchronisateur et CalculateurSup) ou du 

package contenant I a cl asse cai cui ateur vers I ' autre package (dependances dues a I a 
relation d'heritage de la classe CalculateurSup par la classe Caicuiateur et a la 

propriete de type Synchroni sateur de la ClaSSe Cai cui ateur). 



caicuiateur 


CalculateurSup 


> 

* 




-tcalculerQ 



Synchronisateur 






Caicuiateur 




i 




-sync : Synchronisateur 


+calculer() 






+calculer() 



Figure 17 

Suppression du cycle de dependances 

La figure 17 represents I 'ensemble des liens existant entre les classes synchronisa- 
teur, CalculateurSup et Cai cui ateur. Nousavons materialise par un trait la separation 
en deux packages. II est a noter que I 'operation caicuiero est bien declareedans la 
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classe CalculateurSup, alors qu'elle n'est que repetee dans la classe calculateur, ce 
qui n'est pas obi igatoi re. 

Nous pourrions aussi envisager de resoudre le probleme en deportant la propriete 
sync de la classe calculateur, mais cela neferait qu'« agrandir » le cycle de depen- 
dances. La dependance de la classe synchronisateur vers la classe calculateur ne 
peut etre deportee, car el I e est Nee a I'operation caicuiateuro, qui reste dans la 
classe calculateur. L a classe Cai cui ateur heritede la classe CalculateurSup, qui, elle 
meme, depend de la classe synchronisateur en raison desa propriete. 

La figure 18 represente cette mauvaise solution en mettant en evidence le cycle de 
dependances. 



Figure 18 

Echec de la 
suppression du 
cycle de 
dependances 



CalculateurSup 



-synch : Synchronisateur 



Synchronisateur 



+calculer() 



calculateur 



Calculateur 



+calculer() 



38. NOUS SOUhaitons ajoutera la Classe Synchronisateur une operation ajouterCalculateurO 
qui permette d'assignerun calculateur a un synchronisateur, I'identite du calculateur etant 
un parametre d'entree de I'operation. Definissez cette operation. 

La seule difficulte est de faire attention a ne pas creer un cycle de dependances en 
ajoutant cette operation. Les dependances nouvelles creees lors de I'ajout d'une 
operation proviennent des parametres de I'operation. II ne faut absolument pas 
qu'une dependance soit creeedela classe synchronisateur vers la classe caicui ateur. 
Letypedu parametre de I'operation doitdonc etre la classe CalculateurSup. L'opera- 

tion a ajOUter dans la Classe Synchronisateur estalorSdeclarerCalculateur(in recep- 
teur:Cal cul ateurSup). 



calculateur 



CalculateurSup 



+calculer( 



Synchronisateur 



+calculer() 

+ajouterCalculateurt) 



Calculateur 



-sync : Synchronisateur 



-fcalculerf) 



Figure 19 

Ajout de I'operation ajouterCalculateurO 
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La figure 19 represente leS troiS Classes Synchronisateur, Calcul ateurSup et Calcul a- 

teur, ainsi que les liens etablis entre ces classes. 

39. Nous souhaitons maintenant definir une classe representant une barre de progression. 
Cette barre affiche I'etatd'avancementdu calcul (en pourcentage). Une barre de progres- 
sion recoitdes messages d'un calculateur qui I'informe que I'etatd'avancementdu calcul 
a change. Definissez cette classe. 

La figure 20 represente la classe BarreProgression, qui contient I'operation avance- 

ment( ). 



Figure 20 

Classe 

BarreProgression 



BarreProgression 



+avancement() 



40. Toutcomme le synchronisateur, une barre de progression doitse declarer aupres d'un calcu- 
lateur. De plus, le calculateur doit offrir une operation permettant de connaitre le pourcentage 
d'avancementdu calcul. Definissez les associations et operations necessaires. 

II faut modifier la classe calculateur. La barre de progression devant se declarer 
aupres du calculateur, c'estce dernier qui contient I'operation deciarerBarreO. Pour 
que le calculateur puisse identifier la barre qui se declare, il faut que son identite soit 
passee en parametrede I'operation. 

Pour qu' une barre de progression puisseavoir acces a I'etatd'avancementdu calcul, 

il fautcreer une association all ant del a Classe BarreProgression Vers la Classe Calcu- 
lateur et I'operation getAvancementO :integer dans la Classe Calculateur. La multi- 
plicity de I'association est0..1 a I'extremitedu calculateur et 0..* a I'extremite de la 
barre de progression. Une barre de progression estassocieea au plusun calculateur, 
et nous faisons I'hypothese qu'un calculateur est associe a plusieurs barres de 
progression. 

La figure 21 represente les associations et operations ajoutees aux classes BarrePro- 
gression et Calculateur. 

Figure 21 

Classes 

BarreProgression et 
Calculateur apres 
modification 



BarreProgression 


barre calculateur 
> 


Calculateur 






+avancement() 


* 0..1 


+declarerBarre() 
+getAvancement() 



41. Appliquez le patron de conception Observer, et faites en sorte que ces deux classes 
soientdans deux packages differents. 

Lediagrammedonne en response a la question precedente montre qu'il y a un cycle 
de dependances entre les classes BarreProgression et Calculateur. II y a une associa- 
tion de la classe BarreProgession vers la classe cai cui ateur, et le parametre de I'opera- 
tion deciarerBarreO de la ClaSSe Calculateur est de type BarreProgression. NOUS 

devonsdonc « casser » cecycleafin depouvoir mettre les classes dans des packages 
differents. 
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Nous souhaitons lefaireen appliquant le patron de conception Observer, cequi est 
pertinent puisque le probleme resolu par ce patron de conception est : « Creer un 
lien entre un objet source et plusieurs objets cibles permettant de notifier les objets 
cibles lorsque I'etat de I'objet source change. De plus, il faut pouvoir dynamique- 
ment lier a (ou del ier de) I'objet source autantd' objets cibles que nous le voulons. » 

Dans notre cas, I'objet observer est la barre de progression et I'objet subject le 
cal cul ateur, pui sque notre probl erne est d' i nf ormer I a barre de progressi on des avan- 
cements du calculateur. 

L a classe observer du patron de conception correspond a une abstraction de la classe 
BarreProgression dont cette derniere herite. C'est el I e qui doit contenir la methode 
par laquelle la barre de progression est informeedes avancements du calculateur. La 
classe subject du patron de conception correspond a une abstraction de la classe 
calculateur dont cette derniere herite. Dans notre cas, cette classe contient I 'equiva- 
lent de I'operation attachon obs:Observer), qui, dans notre cas, est I' operation 

declarerBarredn barre:Progression) ainsi que I' operation de notification a tOUS les 

observateurs (notifyo). A I'aidedece patron de conception, il est possible def aire 

UnedeCOUpe en packages Separant les Classes BarreProgression et Calculateur. 

La figure 22 represente I'application du patron de conception Observer sur nos 
classes. 



update)) devientavancementO 



attachO devientdeclarerBarreO 



\ 
\ 
\ 

\ 

\ 

1 — \ 


observer 


/ 
/ 

/ 

Subject / 


Observer 
\ 


/ 


-tavancement<) 

A 


< 


-KJeclarerBarYeO 

-tdetachO 

+notify() 



BarreProgression 




0..1 

> 




-tavancementO 




calculateur 



Calculateur 



+declarerBarreO 
+getAvancement() 



Figure 22 

Application du patron Observer 
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42. Ecrivez le code genere a partirde la classe Document illustree a la figure 5.5. 

Figure 23 

Classe Document 



Document 



id:integer 
titre: string 
etatinteger 



definirEtat() 



D'apres les regies de correspondance UML vers Java que nous avons definies, le 
code suivant est obtenu : 

public class Document 
{ 

public int id; 
public String titre; 
public int etat; 

public void definirEtat( 
int etat) 

{ 
) 



Remarquons que les regies suivantes ont ete appliquees : 

• regie n° 1 pour la classe ; 

• regie n° 3 pour toutes les proprier.es de la classe ; 

• regie n° 4 pour I' operation de la classe. 

43. Ecrivez le code genere a partirde la classe Bibiiotheque illustree a la figure 24. 



Figure 24 

Classes 
Bibiiotheque 
et Document 



Bibiiotheque 



ajouterDocumentO 
HsterDocumentO 



doc 



Document 



id:integer 
-^>titre:string 
etatinteger 



definirEtat() 



D'apres les regies de correspondance UML vers Java que nous avons definies, le 
code suivant est obtenu : 

public class Bibiiotheque 
{ 

public java.util .ArrayList doc = new java.util .ArrayListO; 
public void ajouterDocumentO 

{ 
) 

public void 1 i sterDocuntentt ) 
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Remarquons que les regies suivantes onteteappliquees : 

• regie n° 1 pour la classe ; 

• regie n° 4 pour les operations de la classe ; 

• regie n° 5 (deuxieme version) pour I'association vers la classe Document. 

44. Ecrivez le code genere a partir des classes Livre, CD et Revue representees a la figure 25. 
Figure 25 

Classes CD, Livre 
et Revue 



Document 



id:integer 
titre:string 
etatinteger 



definirEtatO 



CD 

CDDB:string 



Livre 

ISBN rstring 



Revue 

ISSN :string 



D'apres les regies de correspondance UM L vers Java que nous avons definies, et 
plus parti culierement grace a la regie n° 6, le code suivant est obtenu : 

public class CD extends Document { 
Public String CDDB; 

} 

public class Livre extends Document { 
Public String ISBN; 



public class Revue extends Document { 
Public String ISSN; 

} 

45. Ecrivez le code genere a partir de I'association CDdeLivre representee a la figure 26 apres 
avoir defini les regies de generation de code que vous comptez utiliser. 



Figure 26 

Association 
CDdeLivre 



CD 


cd CDdeLivre livre 


Livre 


CDDB:string 


ISBN string 


* 0..1 
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A ucune des regies de correspondance UML vers J ava que nous avons rappelees au 
chapitre 5 ne permet de traiter les associations non navigables. Nous pouvons 
proposer la regie suivante : 

Pour toute association non navigable, creer une classej ava. Le nom de la classej ava 
doit correspondre au nom de I'association. Pour chacunr des deux extremites de 
I 'association, creer un attri but dans la classej ava. Le nom de I'attribut doit corres- 
pondre au nom du crochet. Le type de I'attribut doit correspondre a la correspon- 
dance J ava de la classe UML attachee a I'extremite. Si I'extremite sped fie que le 
nombre maximal d'objets pouvant etre relies estsuperieur a 1, 1 'attri but J ava est un 
tableau. 

En appl i quant cette regie a I'association CDdeLivre, nous obtenons le codesuivant : 

public class CDdeLivre { 
CD[] cd ; 
Livre livre ; 

} 

Les objetsjava instances de cette classe permettront ainsi de representor des liens 
entreun livre et des CD. 



46. Ecrivez le code genere a partirdes classes representees a la figure 27 apres avoir defini 
les regies de generation de code que vous comptez utiliser. 

Figure 27 

H eritage multiple 



Document 



id:integer 
titrerstring 
etatinteger 



definirEtatO 



Oeuvre 



TV 



CD 



CDDB:string 



Livre 



ISBN string 



A ucune des regies de correspondance UML vers J ava rappelees au chapitre 5 ne permet 
de traiter I' heritage multiple. Soulignons que la transformation d'un modelea heritage 
multiple vers un modelea heritage simple est un probleme complexetres connu, mais 
sans solution facile a mettre en place. Nous pouvons cependant proposer la regie 
suivante, qui ne s' appl i que qu' a certains modeles, dontcelui denotre question : 

Pour tout modele a heritage multiple dont seule une classe herit.ee possede des 
propriet.es (les autres classes heritees n'en possedent pas) et dont toutes les classes 
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heritees n'heritent pas d'autres classes, creer uneclassej ava pour la classeherit.ee 
qui possede des propri etes, creer une interfacej ava pour les autres classes heritees, 
creer une classe J ava pour la classe qui herite et faire en sorte que celle-ci etende 
la classej ava creee et realise les interfaces J ava creees. 

En appli quant cette regie a notre cas, nous obtenons lecodeci-dessous. 

Lecodede la classe Document est le meme quecelui de la question 42 : 

public interface Oeuvre ( 
} 

Le code des classes cd et Livre change afin de real iser I'interface oeuvre : 

public CD extends Document realize CEuvre ( 
} 

public Livre extends Document realize (Euvre { 

Un mecanisme d'update permet de faire remonter les modifications du code Java 
dans le modele UM L avec lequel il estdeja synchronise. Par exemple, si nousconsi- 
derons que le model e UM L et I e code J ava de la classe Bibiiotheque sont synchro- 
nises depuis la question 43 et que nous ajoutions dans le code I ' attri but nom a la 
classe Bibiiotheque, alors celui-ci apparattra dans le modele UM L apres execution 
de I 'update. 

Nous considerons pour I'instant que le mecanisme d'update correspond a une 
operation de Reverse Engineering du codejava, si cen'estqueleselementsdu code 
qui n'apparaissaient pas dans le modele y sont directement ajoutes. 

47. Construisez le modele UML de la classe Bibiiotheque (dontvous avez fourni le code a la 
question 43) obtenu par update apres avoir ajoute dans le code J ava les attributs nom, 
adresse et type, dont les types sont des string. 

Ces trois attributs, qui n'apparaissaient pas dans le modele, y sont ajoutes selon les 
regies de correspondance du Reverse Engineering. Nous obtenons la classe repre- 
sentee a la figure 28. 



48. Nous voulons maintenant, toujours dans le code J ava, changer rattribut type en attributdomaine. 
Pensez-vous qu'il soit possible, apres un update, que les deux attributs type etdomaine puissent 
etre presents dans le modele ? Si oui, a quoi estdu ce comportement bizarre ? 

A la question precedents nous avons defini I 'update comme une operation ne 
faisant qu'ajouter de nouveaux elements au modele UM L. De ce fait, les elements 
ne sont jamais supprimes du modele UML. L'update ne sait done pas faire la diffe- 



Figure 28 

Classe Bibiiotheque 



nom:string 

adresse:string 

type:string 



Bibiiotheque 



ajouterDocumentO 
listerDocumentO 
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renceentrel'ajoutd'un nouvel attri but et I a modification d'un attribut existant. Des 
lors, il est tout a fait envisageable d'obtenir le modele UML de la classe Bibi io- 
theque represents a la figure 29 avec les deux attri buts type et domaine. 



La synchronisation entre le modele et I e code n'est plus faite. 

49. Proposez un nouveau mecanisme d'update ne souffrant pas des defauts presentes a la 
question precedente. 

Ce nouveau mecanisme d'update doit etre capable defai re la difference entre I 'ajout 
d'un nouvel attribut et la modification d'un attribut existant. 

Pour ce faire, I'update doit etre capable de reconnattre chaque attribut Java et de 
verifier qu'il n'existe pas uneproprietecorrespondante dans lemodeleUM L. Si une 
propriete existe deja, il faut la modifier. L' update doit done lier les attri buts Java aux 
proprietes UML pour chaque classe. 

C e I i en ne peut se fai re sur I e nom des attri buts et des propri etes. E n eff et, I a modi ficati on 
du nom de I 'attri but Java rendrait impossible la recherche de la propriete UM L corres- 
pondante et entramerait les memes problemes de perte de synchronisation. 

La solution classique a ce probleme consiste, d'une part, a introduire dans le code 
Java des commentaires permettant d'identifier chaque attri but et, d'autre part, a lier 
ces identifiants aux identifiants des proprietes UML. 

Le code suivant de la classe Bibi iotheque ill ustre cette utilisation des commentaires : 



public class Bibl iotheque 
{ 

//attribut idl 
public String nom; 

//attribut id2 

public String adresse; 

//attribut id3 

public String type; 

public java.util .ArrayList doc = new java.util .ArrayListO; 

public void ajouterDocument( ) 

{ 

) 

public void 1 i sterDocumentt ) 



Figure 29 



Bibliotheque 



Classe Bibliotheque 
apres modification 
dela propriete type 
en domaine 



nom:string 
adresse:string 
type:string 
domaine:string 



ajouterDocument() 
listerDocumentO 
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En liant ces identifiants aux identifiants des proprietes UM L, il est possible de realiser 
unecorrespondanceentrechaqueattributJavaetchaqueproprieteUM L etainsi d'effec- 
tuer les modifications des proprietes U M L lorsque les attributsj ava sont modifies. 

50. Proposez le mecanisme inverse de I'update permettantde modifier un modele UML deja 
synchronise avec du code et de mettre a jour automatiquement le code J ava. 

Ce mecanisme ressemblefortement a I'update, si cen'estqu'il s'appuiesur I 'opera- 
tion degeneration decode. Les identifiants des attributsj ava doi vent tout autantetre 
utilises afin de permettre la modification des proprietes UM L et la modification des 
attri buts J ava correspondants. 

51. Dans quelle approche de programmation par modelisation (Model Driven, Code Driven et 
Round Trip) ces mecanismes d'update sont-ils fondamentaux ? 

Ce mecanisme est reellement necessaire pour I 'approche Round Trip, qui permet la 
modification du modele et du code a n'importe quel moment et doit done assurer 
finement la synchronisation. Ce mecanisme n'est pas i nteressant pour les approches 
Model Driven ou Code Driven, car ces deux approches n'utilisent I'operation de 
generation decodeou de Reverse Engineering qu'unefois. 



TD6. Diagrammes de sequence 



Lapplication Champi onnatEchecs, qui doit permettre de gerer le deroulement d'un championnat 
d'echecs, est actuellement en cours de developpement. Lequipe de developpement n'a pour 
I'instant realise qu'un diagramme de classes de cette application (voir figure 30). 



Figure 30 

Classes de 

I ' appl ication 

ChampionnatEchecs 



-MAX:integer 
fermenboolean 



ChampionnatDEchecs 



+inscriptionJ oueur() 
+genererParties() 
+obtenirPartiesDUn| oueur() 
+calculerClassementDUnJ oueurf) 



joueur 



Joueur 



■numero:integer 

■nom:string 

■prenom:string 



7^ 



partie 



Partie 



■numero:integer 
■fini iboolean 



+jouerCoup() 
-verifierMatf) 
-finirP artie() 



~7K 



blanc 
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La classe ChampionnatDEchecs represente un championnat d'echecs. Un championnat se 
deroule entre plusieurs joueurs (voir classe Joueur) et se joue en plusieurs parties (voir 
classe Partie). La propriete MAX de la classe ChampionnatDEchecs correspond au nombre 
maximal de joueurs que le championnat peut comporter. La propriete fermer permet de 
savoir si le championnat est ferme ou si de nouveaux joueurs peuvent s'inscrire. 

ChampionnatDEchecs possede les operations suivantes : 

• inscriptionJoueur(in norrustring, in prenom:string) : integer permettant d'inscrire un 
nouveau joueur dans le championnat si le nombre de joueurs inscrits n'est pas deja 
egal a MAX et si le championnat n'est pas deja ferme. Si I'inscription est autorisee, cette 
operation cree le joueur et retourne son numero dans le championnat. 

• genererPartie( ) : permet de fermer le championnat et de generer toutes les parties 
necessaires. 

• obteni rPartieDUnJoueur(in numero:integer) :Partie[*] : permet d'obtenir la liste de 
toutes les parties d'un joueur (dont le numero est passe en parametre). 

• calculerClassementDUnJoueur(in numero :interger) : integer permettant de calculer le clas- 
sement d'un joueur (dont le numero est passe en parametre) pendant le championnat. 

La classe Partie represente une des parties du championnat. La classe Partie est 
d'ailleurs associee avec la classe ChampionnatDEchecs, et I'association precise qu'un cham- 
pionnat peut contenir plusieurs parties. Une partie se joue entre deux joueurs. Un joueur 
possede les pieces blanches et commence la partie alors que I'autre joueur possede les 
pieces noires. Les associations entre les classes Partie et Joueurs precisent cela. La 
propriete numero correspond au numero de la partie (celui-ci doit etre unique). La propriete 
fini permet de savoir si la partie a deja ete jouee ou non. 

La classe Partie possede les operations suivantes : 

• jouerCoupd'n coup: string) : permet de jouer un coup tant que la partie n'est pas finie. 
Le traitement associe a cette operation fait appel a I'operation verifierMat afin de 
savoir si le coup joue ne met pas fin a la partie. Si tel est le cas, I'operation finirPartie 
est appelee. 

• verifierMat( ) : boolean permettant de verifier si la position n'est pas mat. 

• finirPartie : permet de preciser que la partie est finie. II n'est done plus possible de 
jouer de nouveaux coups. 

La classe Joueur represente les joueurs du championnat. La classe Joueur est d'ailleurs 
associee avec la classe ChampionnatDEchecs, et I'association precise qu'un championnat 
peut contenir plusieurs joueurs. La propriete numero correspond au numero du joueur 
(celui-ci doit etre unique). Les proprietes nom et prenom permettent de preciser le nom et le 
prenom du joueur. 

Un championnat d'echecs se deroule comme suit : 

• Un administrateur de I'application cree un championnat avec une valeur MAX. 

• Les participants peuvent s'inscrire comme joueurs dans le championnat. 

• Ladministrateur cree I'ensemble des parties. 

• Les participants, une fois inscrits, peuvent consulter leur liste de parties. 

• Les participants, une fois inscrits, peuvent jouer leurs parties. Nous ne nous interessons 
qu'aux coups joues par chacun des deux joueurs. Nous ignorons I'initialisation de la partie 
(identification du joueur qui a les pions blancs et done qui commence la partie). 

• Les participants peuvent consulter leur classement. 
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Dans les questions suivantes, nous allons specifier des exemples d'execution de Cham- 
pi onnatDEchecs avec des diagrammes de sequence. 

52. Comment modeliser les administrateurs et les participants ? 

Les administrateurs et les participants ne font pas partie de I'application, mais ils 

I ' Uti I i Sent. Voi I a pourquoi, il n'existepasdedaSSeAdministrateur ni Participant. II 

est tres important de distinguer le participant de I' instance de la classe Joueur. 
L'instance de la classe Joueur est un objet qui fait partie de I'application et qui 
contient differentes informations sur un participant. 

Pour faire apparaitre les participants et les administrateurs dans les diagrammes de 
sequence, il faut utiliser des objets non types. 

53. Representez parun diagramme de sequence le scenario d'execution correspondanta la 
creation d'un championnateta I'inscription de deuxjoueurs. Vous assurerez la coherence 
de votre diagramme avec le diagramme de classes fourni a la figure 30. 

Le diagramme de sequence solution represente a la figure 31 contient six objets. 
L'objet Tadministrateur n'est pas type et represente I'administrateur. Les objets 
MrBF et MrBS ne sont pas types non pi us et representent respecti vement I es deux parti - 
cipants au championnat. L'objet umione est instance de la classe championnatDEchecs 
et represente I e championnat. Les objets bf et bs sont instances de la classe joueur et 
representent les deux joueurs du championnat. 

Le diagramme de sequence specifie que Tadministrateur commence par creer 
l'objet umione puis que MrBF et MrBS demandent a s'inscrire au championnat en 
donnant leur nom et leur prenom. En reponse aux deux demandes d'inscription, 
umione cree les deux objets bf et bs instances de la classe j oueur et retourne les 
numeros d' identification des ioueurs. 



bossAdministrateur 




MrBF 




MrBS 













umlOne:ChampionnatDEchecs 



insjxiptionj oueur ("bobby", "fisher") 



■r- 



inscriptionj oueur( "Boris", "Spassky"] 



bf:l oueur 



bs:l oueur 



Figure 31 

Diagramme de sequence representant des inscriptions 



54. Representez par un diagramme de sequence le scenario d'execution correspondanta la 
creation de I'ensemble des parties pourle championnat cree a la question 53. Vous assurerez 
la coherence de votre diagramme avec le diagramme de classes fourni a la figure 30. 
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Le diagramme de sequence solution represents a la figure 32 contient trois objets. 
L'objet radministrateur est le meme qu'a la question 53. II demande a I'objet 
umione de real iser I 'operation genererPartieo. Celui-ci, qui est aussi le meme objet 
qu'a la question precedents creeuneseule partie, representee par I'objet pi instance 
de la classe Partie, car lechampionnat ne contient que deux joueurs. 



Figure 32 

Diagramme 
de sequence 
representant 
la generation 
des parties 



I'administrateur 



umlOne:C hampionnatDEchecs 



genererPartiesO 



creation 



pJjParjje 



55. Representez par un diagramme de sequence le scenario d'execution correspondant au 
deroulement de la partie d'echecs entre deux joueurs. Vous pouvez considerer une partie 
qui se termine en quatre coups. Vous assurerez la coherence de votre diagramme avec le 
diagramme de classes fourni a la figure 30. 

Le diagramme de sequence solution represents a la figure 33 contient trois objets. 
Les objets MrBF et MrBS sont les memes qu'a la question 53. L'objet pi est le meme 
qu'a la question 54. Ce diagramme sped fie les differents coups joues par les deux 
participants et le fait que nous verifions a chaque coup que la position n'est pas mat. 
Au dernier coup, la position est mat. La partie est done terminee. 

56. Est-il possible de generer automatiquement le code d'une operation de cette application 
a partir de plusieurs diagrammes de sequence ? 

Commenous I'avonsvu en cours, il n'est pas reel I ementpossiblede generer I e code 
d'une operation. Cela est parti culierement flagrant avec I' operation jouerCoup. N OUS 
voyons bien qu'il n'est pas possible de real iser tous les diagrammes de sequence 
correspondant a toutes les executions possibles de cette operation. 

57. Est-il possible de construire des diagrammes de sequence a partir du code d'une 
application ? 

Lorsquenousdisposonsdu code d'une application, il est possible de I 'ex ecuter. De 
ce fait, i I est possi bl e de construi re un di agramme de sequence representant scrupu- 
leusement cette execution. 

Par exemple, nous pourrions executer I ' appl i cati on de gestion de championnat 
d'echecs pour un championnat particulier et modeliser cette execution dans un 
diagramme de sequence. Notons que cette fonctionnal ite est par ailleurs souvent 
proposee par les outils du marche. 
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Figure 33 

Diagramme 
de sequence 
represents nt 
une partie 



MrBF 



MrBS 



jouerCoup("f4") 




pl:Partie 

1 

I 

* 




jouerCoup("e6") I 
ti 



verifierMatO 
'j faux 

verifierMatO 



P( ,, g4") 



I ~ ~\> faux 

t ** 

"I 



1 — 



jouerCoup("Dh4") j 
H 



verifierMatO 
'j faux 

verifierMatO 



I **> vrai 



I — 

x- - 



finirPartief) 
ok 



1 1 est i mportant de noter que I es di agrammes obtenus ne represented qu' une execu- 
tion de I ' appl i cati on. L'ensemble des diagrammes de sequence obtenus a partir du 
code de I'operation ne peuvent done etre utilises ulterieurement a des fins de gene- 
rati on automati que de code. 

Une equipe de developpement souhaite realiser une application Calculus permettant a 
des utilisateurs d'effectuer des operations arithmetiques simples sur des entiers : addi- 
tion, soustraction, produit, division. Cette application a aussi une fonction memoire, qui 
permet a I'utilisateur de stocker un nombre entier qu'il pourra ensuite utiliser pour 
n'importe quelle operation. Les operations peuvent s'effectuer directement sur la 
memoire. Lutilisateur se connecte et ouvre ainsi une nouvelle session. Puis, dans le 
cadre d'une session, il peut demander au systeme d'effectuer une suite d'operations. 
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58. Utilisez des diagrammes de sequence pour representer les differents scenarios d'execu- 

tion du service Calculus. 

L'objectif de cette question est d'illustrer lefait qu'il est possible de commencer a 
modeliser une application par I'elaboration de sequences plutot que par I 'elabora- 
tion de classes. 

L e diagramme represents a la figure 34 specifie une demande de creation de session 
puis la realisation d'une addition etd'une multiplication. 



Figure 34 

Diagramme 
de sequence 
representant 
une addition 
et une multiplication 



I'utilisateur 



a pplicationP rincipa le 



creerSession 



creation 



addition(l,2) 



i 



I 



2 I 
J 
I 
I 
I 
I 



nouvelleSession 




L e diagramme represents a la figure 35 specifie une demande de creation de session 
puis I'affectation de la memoire a 2, puis I'ajout de 2 a la memoire (la memoire 
contientdonc 4). 

59. Pour chacune des instances apparaissant dans votre diagramme de classes, creez la 
classe correspondante. 

Les diagrammes de sequence que nous avons proposes a la question 58 nous 
permettent de proposer le diagramme de classes represents a la figure 36. 

Ainsi, I'objet appiicationPnncipaie est-il instance de la classe 

ApplicationArtihmetique et I'objet nouvelleSession est-il instance de la ClaSSe 

session. En multi pi i ant ai nsi les diagrammes de sequence, nous pouvons obtenir un 
diagramme de classes beaucoup plus complet. 
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Figure 35 

Diagramme 
de sequence 
represents nt 
un ajout 

dans la memoire 



I'utilisateur 



a pplicationP rincipa le 



creerSession 



I 



I creation 

I ► 
J 
I 



stockerMemoire(2) 



nouvelleSession 




Figure 36 

Classe 

A pplicationA rithmetique 



ApplicationArithmetiquE 



+creerSession() .'Session 



session 



Session 



+stockerMemoire() 
+ajouterMemoire() 
+addition() 
+multiplication () 



Nos diagrammes de sequence nefont pas apparaitre les operations soustractiono, 

divisionO, soustrai reMemoi re( ), diviserMemoireO, multipl ierMemoi re( ), etc., que 

I' application devrait logiquement offrir. Comme nous deduisons notre diagramme 
de classes des diagrammes de sequence, il est logique que ces operations n'appa- 
raissent pas non plus dans la classe session. 
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TD7. Diagrammes de sequence de test 

La classe Partie de I'application de gestion de championnatd'echecs presentee auTD6 repre- 
sente une partie d'echecs. Elle permet auxjoueurs de jouer leur partie en appelant I'operation 
jouer-CoupO. Chaque fois qu'un coup est joue, I'operation verifierMato est appelee afin de 
verifier que la position n'est pas mat. Si tel est le cas, la partie est finie. Aucun coup ne peut 
alors etre joue (voir TD6 pour la moderation de classe Partie ainsi qu'un diagramme de 
sequence specifiant un cas nominal de deroulement d'une partie entre deux joueurs). 

60. Identifiez une faute qui pourrait intervenir lors du deroulement d'une partie. 

U ne faute potenti el le serai t que I'operation verifierMato ne retourne pas vrai alors 
que la partie est reellement mat. Si tel etait le cas, la partie neserait pas finie, et les 
joueurs pourraient continuer a jouer leurs coups. 

A I'inverse, une autre faute serait que I'operation verifierMato retourne vrai alors 
que la partie n'est pas mat. Si tel etait lecas, la partie serait finie, et les joueurs ne 
pourraient plus continuer a jouer leurs coups. 

61. Definissez un cas de test abstrait visant a reveler cette faute. 

Si nous nous concentrons sur la premiere faute que nous avons identifiee a la 
questi on 60, un cas de test abstrait vi sant a revel er cette faute serait de si mul er I e j eu 
d'une partie jusqu'a un mat. Le resultat attendu serait que la partie soit fermee a 
I'issuede la simulation. 

62. Construisez un diagramme de sequence de test modelisant le cas de test abstrait de la 
question precedents. 

Comme illustre a la figure 37, le diagramme de cas de test doit contenir le testeur 
(objet a gauche du diagramme). Celui-ci doit creer I'objet a tester (I'objet instance 
de la classe Patie), puis le testeur doit stimuler I'objet a tester. Dans notre cas, le 
testeur fait semblant dejouer une partie jusqu'au mat. Enfin, le diagramme de cas 
detest doit specifier le resultat attendu. Dans notre cas, la partie doit etre finie. 

La suite de coups representee dans le diagramme suivant correspond a une partie 
reelleamenantau matdu roi blanc en quatre coups. 

63. Ecrivez le pseudo-code Java du cas de test executable correspondant au cas de test 
abstrait de la question precedents. 

En suivant les regies de correspondance decrites dans le cours, nous obtenons le 
code suivant: 

public class Test extends TestCase{ 
public void testExecutabl e( ) { 
pi = new Partie( ) ; 
pi. jouerCoup("f4") ; 
pi. jouerCoup("e6") ; 
pi. jouerCoup("g4") ; 
pl.jouerCoup("Dh4") ; 
assertTrue(pl.fini ) ; 

} 

}. 
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Figure 37 

Diagramme 

de sequence detest 

de la classe Partie 



teste ur: 



creation 



jouerCoup('f4") 



pl:Partie 



I 



K 


jouerCoup("e6") 


»l 


k— ■ 


jouerCoup("g4") 






jouerCoup("Dh4") 


— h 
— *l 


k — 







resultatattendu: 
pl.fini =true 



La derniere lignedececode permet de verifier que la partie est bien terminee. 

64. Si ce cas de test ne revele pas de faute, est-ce que cela signifie que I'application ne 
contient pas de defaillance ? 

A bsolument pas. Cela signifie simplement que, pour cette suite de coups (f4, e6, g4, 
Dh4), I'application ne revele pas de faute. U ne autre suite de coups pourrait reveler 
une faute qui indiquerait que I'application contient une defaillance. 

65. Combien de cas de test faudrait-il elaborer pour ameliorer la qualite de I'application ? 

M alheureusement, real i ser un grand nombre de cas de test n' off re pas plus de garantie 
sur la non-existence de defaillance dans une application. Cela se voit bien dans ce cas, 
puisqu'il faudrait realiser un cas de test abstrait pour chaque parti ed'echecs imaginable. 

L' application permettantlagestiondechampionnatd'echecscontientaussi la classe 
championnatDEchecs, qui est associee a la classe Partie et qui permet de gerer 
I'inscription des joueurs et la creation des parties (voirTD6). 
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66. Identifiez une faute qui pourrait intervenir lors de la creation des parties d'un cham- 
pionnat. Definissez un cas de test abstrait visant a reveler cette faute, et construisez un 
diagramme de sequence de test modelisant ce cas de test abstrait. 

Une faute potenti el le serait que toutes les parties du championnat ne soient pas 
creees ou qu'il y en ait plus que necessaire. II serait alors impossible a tous les 
joueurs dejouer leurs parties ou la fin du championnat ne serait jamais atteinte. 

U n cas de test abstrait permettant de revel er cette faute serait de construi re un cham- 
pionnat avec deux joueurs et de verifier qu'apres construction des parties, il existe 
bien exactement une seule parti e. 

Le diagramme represents a la figure 38 specifie ce cas de test abstrait. Le testeur 
cree I'instance de la classe ChampionnatDEchecs. II simule ensuite I'inscription de 
deux joueurs puis demande la generation des parties. Le resultat attendu est que le 
championnat ne contienne qu'une seule partie. 



Figure 38 

Diagrammede sequence 
de test de la classe 
ChampionnatDEchecs 



Testeur 



creation 



umlOne:ChampionnatDEchecs 



inscription] oueur("bobby", "fisher") 



K ■ 

inscription] oueur("Boris","Spassky") 



k J 



genererPartiesO 



f , 

' I k ' 

resultat attendu 

umlOne reference 1 seule partie 



67. Est-il possible de lier les deux cas de test abstrait que vous avez definis (un a la 
question 61, 1'autre a la question 66) ? 

II est en effet possible de demarrer le cas de test abstrait de la question 61 apres le 
cas detest abstrait de la question 66. Pourcefaire, il faudrait modifier un peu lecas 
de test de la question 61 afin de preciser que le testeur n'a pas a creer la partie a 
tester mais peut I'obtenir puisqu'elle est liee au championnat dej a cree. 
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TD8. Plates-formes d 'execution 

68. Le diagramme de classes de I'agence de voyage represents a la figure 39 correspond-t- 
il a un modele conceptuel ou a un modele physique ? 



Hotel 


hotel 

< 


Reservation 


-name:string 


-dateArrivee:string 
-dateDepartstring 


0..1 * 




+setHotel() 



hotelPropose 



reservationEffectOee 




+obtenirReservation() 
+demanderTarifs() 



Figure 39 

Classes de I'agence de voyage 



L'application « agence de voyage » doit gerer les reservations d'hotels effectuees 
par des clients. Les trois classes qui apparaissent dans le diagramme sont les objets 
metier de I 'appl i cation. Les operations offertes par ces classes sont les fonctions que 
nous souhaitons pouvoir real i ser lors de la reservation d'un hotel : obtenir les tarifs 
d'un hotel et effectuer la reservation. Le diagramme represents done les objets et 
fonctions metier. Aucune information ne nous permet de I'assimiler a un modele 
physique : il n'y a pas declasse Java et il n'y a pas declasse ne representant pas un 
objet metier. Nous pouvonsdonc direqu'il s'agitd'un modele conceptuel. 

69. Pensez-vous qu'il soit interessant d'appliquer des patrons de conception sur les modeles 
conceptuels ? 

Tout depend du but dans lequel I e patron de conception est utilise. 

Si I'objectif est de « casser » les dependances et/ou de proposer une decoupe du 
modele en packages, cela peut etre interessant. Nous obtenons des classes 
abstraites, des interfaces, des associations, des packages, etc., et ces objets ont tout 
a fait leur place dans un modele 100 % UM L sans qu'il soit necessaire de le lier a 
Java, lis sont done pertinents dans un modele conceptuel. 
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Si I'objectif est d'appliquer les patrons en vue de beneficier du code qu'ils propo- 
sed, eel a n'est pas interessant, car nous integrons a un model e conceptuel des 
contraintes specifiques a une plate-forme d'execution. 

Prenons I'exempledu patron de conception Singleton. 

Ce patron fait en sorte qu' i I n'y ait qu' une seule et unique i nstance d' une cl asse dans 
une application. La mise en place de ce patron ne se fait que par du code (Java par 
ex em pie) : 

public class A { 

static singleton = new AO; 
publ ic A ( ) { 

return singleton ; 

} 

Ce patron de conception n'est done pas applicable en 100 % UM L (modele concep- 
tuel), car sa mise en place necessite I' integration decode dans le modele. Le patron 
de conception Observer, que nous avons deja vu, est en parti e applicable, car une 
partie de son utilisation consiste en la creation de classes et d' associations entre 
el les (decoupe en classeabstraite, heritage, etc.). Par contre, le code des operations 
du patron de conception n'est pas utilisable (methodes attache ), notifyAiio, etc.) 
puisqu'il nes'agitpasd'informations 100% UML. 

Nous venons de voir que I'application de patrons de conception au niveau concep- 
tuel etait possible et utile mais qu'elle devait etre effectuee avec precaution pour ne 
pas introduiredes considerations physiques la ou el les ne doivent pas se trouver. 

70. Le diagramme de sequence represents a la figure 40 est-il conceptuel ou physique ? 
Notez qu'il fait intervenir une operation qui n'apparait pas dans le diagramme de classes 
initial. Quelle classe doit posseder cette operation ? 



client: aa:AaenceDeVovage 
obtenirReservation("R itz","15juin ","16juin ") 



ok 



K-- 



creation 



resa:Reservation 



addReservationEffectuee(resa) 



Figure 40 

Interaction representant une reservation 
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Les classes nominees qui apparaissent dans ce diagramme de sequence sont les 
classes du modele conceptuel. II s'agit done d'un diagramme de sequence concep- 
tuel. Un diagramme de sequence d'un certain niveau d' abstraction ne peut faire 
intervenir que des classes du meme niveau d' abstraction. 

L'operation qui a ete ajoutee est addReservationEffectueeO. Le diagramme de 
sequence montre qu'elle doit etre mise dans la classe AgenceDeVoyage et qu'il s'agit 
d'une operation interne a cette classe. 

71. Serait-il possible de specifier en 100 % UML le comportementde I'agence de voyage ? 

Les model es U M L que nous considerons utilisent les diagrammes de sequence pour 
representer la partie comportementale d'une application. Pour pouvoir specifier en 
100 % UML le comportement de I'agence de voyage, il faudrait done produire un 
ensemble de diagrammes de sequence representant de maniere exhaustive 
I'ensemble des comportements possibles de I ' appl i cati on. En regie general e, e'est 
i mpossi bl e pui sque I e nombre de di agrammes a produi re est trap i mportant. 

Dans notrecas, c' est total ement impossible, parcequ'un certain nombre dedonnees 
peuvent prendre un nombre infini de valeurs (attributs de type string) et que les 
diagrammes de sequence doivent prendre en compte toutes les valeurs possibles. 
Nous ne pouvons done pas specifier en 100 % UML le comportement de I'agence 
de voyage a I'aide de diagrammes de sequence. 

II est important de noter que si d'autres diagrammes UML sont pris en considera- 
tion, le probl erne peut trouver une solution en 100 % UM L. Nousavons pris le parti 
dans ce cours de ne presenter que les trois plus importants des diagrammes UML, 
car ils sont suffisants pour I'approche que nous utilisons. 

72. Serait-il possible de specifieren 100 % UML des tests pour I'agence de voyage ? J ustifiez 
I'interetde ces tests. 

Oui, rien nel'empeche. II fauttoutefois avoir conscience que ces tests serai ent des 
tests abstraits, done non executables. II faudrait des lors faire les tests physiques 
correspondants pour qu'ils soient executables apres generation du code. 

73. Le diagramme represents a la figure 41 est une concretisation du diagramme conceptuel 
de I'agence de voyage. Exprimez les relations d'abstraction entre les elements des deux 
diagrammes. 

II s'agit d' identifier les relations d'abstraction entre les elements du diagramme 
physique et ceux du diagramme conceptuel. Les elements a considerer sont les 
classes et les associations. II faut garder en memoire que tout element du niveau 
conceptuel doit etre associe a au moins un element du niveau physique. L'inverse 
n'est pas vrai. 

Nous devons done trouver les elements representant la concretisation de : 

• la ClaSSe Hotel ; 

• la ClaSSe Reservation ; 

• la ClaSSe AgenceDeVoyage ; 

• I'aSSOCiation hotel Propose ; 
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Hotel 


hotel 


Reservation 


-dateArrivee:string 
-dateDepartstring 


-name:string 


< 

0..1 







reservation Effectuee 



0..1 



Array Li st 



hotelPropose 



AgenceDeVoyage 



+obtenirReservation() 
+demanderTarifc() 



4next() 
+iiasNext() 



\ 

Reservation res^iull; 

for (Iterator it = reservation Effectuee. iteratort) ; ithasNextO ; ) { 

Reservation current= (Reservation) itnextO; 

if (currentdateArrivee =dateArrivee 
&&current.dateDepart= dateDepart 
&&current.hotel.name = hotelName) return current 

} 

res = new Reservation(dateArrivee , dateDepart); 
res.setHotel(new HoteO); 
return res 

} 



Figure 41 

Classes du niveau physique de I'agence de voyage 

• I 'association hotel ; 

• I'aSSOCiation reservationEffectuee. 

Pour les classes, c'est assez facile et naturel. Chaque classe du model e conceptuel est 
I'abstraction de la classe de meme nom du modele physique. L'association hotel de 
multiplicite 0..1 est concretises par l'association de meme nom avec la meme multipli- 
city Les associations hotel Propose et reservationEffectuee sontun peu pi us del icates a 
gerer car el les ont une multiplicite*. E I les sont concretises par l'association de meme 
nom, et la classe ArrayList est uti I i see pour representor la multiplicite *. La classe 
ArrayList participedonc a la concretisation dedeux relations. II fautnoter que la classe 
iterator n'est la concretisation d'aucune classe du niveau conceptuel. 

Les relations d' abstraction entre diagrammes de classes peuvent etre ajoutees aux 
diagrammes UM L. 

74. Quel est I'interet d'avoir fait apparaitre les classes ArrayList et iterator dans le modele 
concret (considerez en particulier la generation de code etle Reverse Engineering) ? 

L'interet est d'avoir un modele physique tres prochedu code Java. Ainsi, I 'operation de 
generation de code (et de Reverse Engineering) est-elle beaucoup moins complexe et 
done beaucoup plus sure. M ais, comme nous I'avons vu avec la classe ArrayList et les 
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deux associations du niveau conceptuel a la concreti sation desquelles el le parti cipe, 
etablir les relations d' abstraction entre le model e conceptuel et les elements physiques 
tres pres du code n'est pas simple. L a classe iterator nous montre en outre que certains 
elements du model e physique nesont relies avec aucun element du model e conceptuel. 
E lie est juste presente pour la generation de code J ava. 

En fait, plus le modele physique est proche dejava, moins la generation de code est 
complexe, mais plus les relations d' abstraction sont importantes et complexes. A 
I 'inverse, moins le modele physique est proche dej ava, plus la generation de code est 
complexe, mais I'etablissementdes relations d' abstraction en estnormalementfacilite. 

75. Construisez le diagramme de sequence concretisant le diagramme de sequence 
presente a la question 70. 

II s'agit quasi mentdu meme diagramme, si ce n'est que le addReservationEffectuee 
devient add et se fait directement sur I'instance de ArrayList I iee a I'objet ag. Cette 
instance de ArrayList est identifiee par reservationEffectuee dans le diagramme 
represented la figure 42. 



client: 




aa:AaenceDeVovaae 








reservationEffectuee: 
ArravList 


' obtenirR eservation( "R itz","15juin 


,"16juin") ' 

►! 


creation 




resa:Reservation 












add(resa) 
















— h 




ok 






r 






k 















Figure 42 

Interaction du niveau physique representant une reservation 



76. Exprimez les relations d'abstraction entre les diagrammes de sequence. 

Les relations d'abstraction ne peuvent apparaitre entre diagrammes de sequence. 
Notre modele ne nous permet done pas de les exprimer. 
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TD9. Diagrammes de cas d'utilisation 

Le diagramme de cas d'utilisation de la figure 43 represente les fonctionnalites d'une 
agence de voyage classique. 



Agence De Voyage 




Figure 43 

Diagramme de cas d'utilisation de I 'agence de voyage 



77. Commentez les acteurs du diagramme de cas d'utilisation. 

L' acteur client represente I es cl i ents de I ' agence et I ' acteur voyageur represente I es voya- 
geurs. C omme i I s' agi t d' entites externes a I ' appl i cati on, ri en ne garanti t qu' un voyageur 
soitobligatoirement client del'agence. Done, memesi certains voyageurs peuventetre 
clients del 'agence, il nefautpas mettrede relation d'heritageentrecesdeux classes. 

78. Commentez les cas d'utilisation du diagramme de cas d'utilisation. 

Ce diagramme laisse croire que e'est I'agence de voyage qui s'occupe de la realisa- 
tion du voyage, ce qui n'est generalement pas le cas. L'agence se charge normale- 
ment de vendre des voyages realises par d'autres. II n'est des lors pas souhai table 
d'associer ce cas d'utilisation a I ' appl i cati on « agence de voyage ». Nous suppri- 
mons done ce cas, et, en consequence, nous supprimons I'acteur voyageur, qui n'est 
plus relie a aucun cas d'utilisation du diagramme. 

Le diagramme d'utilisation de cette question represente les fonctionnalites du 
systeme vis-a-vis des entites externes qui interagissent avec lui. II s'agit du 
diagramme de cas d'utilisation decrivant les fonctionnalites de I ' appl i cati on au 
niveau besoin. II ne faut done faire apparattre que les fonctionnalites du systeme 
(quels services rend le systeme ?) et ne donner aucune information sur la fagon dont 
ces fonctionnalites sont real i sees (comment les services sont rendus ?). 
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Les relations d'inclusion (include) represented une decoupe fonctionnelle. Elles 
nous informent que, pour realiser le cas d'utilisation Reserver voyage, il peut etre 
necessaire de realiser les cas d'utilisation Annuler Reservation et Payer voyage. Ces 
informations n'ontri en afaireau niveau besoin ; il s'agitd'informationsqui ontleur 
place au niveau conceptuel. II en va de meme des relations d'inclusion entre le cas 

d'utilisation Payer Voyage et les CaS d' Utilisation Donner Cheque et Donner CB. 

La relation d'extension (extend) represente I'ajout d'une fonctionnalite non prevue 
initialementdans I e cas d' utilisation Payer voyage. I ci, il a ete ajoute la possibilitede 
payer la reservation par leWeb. Dans ce cas precis, cette extension n'est pas justi- 
fiee, car ce cas d' utilisation ne presente pas une extension de comportement mais un 
troisiememoyen depaiement, lequel n'a pas davantage sa place dans cediagramme 
que les deux precedents. 

II est important de retenir que I'application doitoffrirau clientla possibilitedefaireune 
reservation, de payer une reservation, d' annuler une reservation et d'obtenir un devis. 

La figure 44 represente le diagramme de cas d'utilisation que nous obtenons. 



79. Donnez la liste des acteurs du systeme. 

Nous souhaitons realiser le diagramme de cas d'utilisation du championnat 
d'echecs presente auTD 6. 

La description de I'application donnee au TD6 nous permet d'en identifier trois : 
I'administrateur, le participant, qui represente un individu qui va s'inscrire a un 
championnat, etlejoueur, qui represente un individu inscrit a un championnat etqui 
peut done parti ci per aux parties auxquelles il est inscrit. 

II ne faut pas etablir de lien d' heritage entre les acteurs Participant et Joueur, car 
tous les participants ne sont pas des joueurs. lis ne le deviendront qu'apres s'etre 



Figure 44 

Diagramme de cas 
d'utilisation de 
I'agence de voyage 
apres correction 




Agence De Voyage 
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inscrits. Or tous les joueurs ne sont pas obligatoirement des participants puisque 
rien n'oblige un joueur a s'inscrire a un nouveau championnat. 

80. Donnez la liste des cas d'utilisation du systeme en les liantaux acteurs. 

Les cas d'utilisation associes a I 'administrateur sont : 

• creer un championnat ; 

• creer I 'ensemble des parties associees a un championnat. 
Les cas d'utilisation associes au participant sont: 

• s'inscrire a un championnat. 

Les cas d'utilisation associes au joueur sont : 

• consulter lecalendrier lui donnant les informations sur sa liste de parties ; 

• jouer les parties d'un championnat ; 

• consulter son classement. 

81. Donnez le diagramme de cas d'utilisation du systeme. 

Le diagramme de la figure 45 represente les cas d'utilisation de I ' appl i cati on du 
championnat d'echecs. 




82. Reprenez les diagrammes de sequence realises au TD6 pour I'application de cham- 
pionnat d'echecs, et expliquez comment les relier au diagramme de cas d'utilisation 
obtenu a la question precedente. 

II faut juste fai re le lien entre I esobjetsnon types des diagrammes de sequence et les 
acteurs du diagramme de cas d'utilisation. A insi, I'objet i' administrateur devient-il 



Corriges des TD 



Chapitre 11 



une instance de I'acteur Administrates. Dans le diagramme de sequence represen- 
tant I' inscription a un championnat, les objets mtbf et mtbs deviennent des instances 
de I'acteur Participant. Dans le diagramme de sequence representant le deroule- 
ment d'une parti e, les objets mtbf et mtbs deviennent des i nstances de I 'acteur joueur. 



TDIO. Developpement avec UML 

Une association d'ornithologie vous confie la realisation du systeme logiciel de recueil et 
de gestion des observations realisees par ses adherents (le logiciel DataBirds). L'objectif 
est de centraliser toutes les donnees d'observation arrivant par differents canaux au sein 
d'une meme base de donnees, qui permettra ensuite d'etablir des cartes de presence des 
differentes especes sur le territoire gere par I'association. 

Les donnees a renseigner pour chaque observation sont les suivantes : 

• Nom de I'espece concernee. II y a environ trois cents especes possibles sur le territoire 
en question. Si I'observation concerne plusieurs especes, renseigner plusieurs obser- 
vations. 

• Nombre d'individus. 

• Lieu de I'observation. 

• Date de I'observation. 

• Heure de I'observation. 

• Conditions meteo lors de I'observation. 

• Nom de chaque observateur. 

Quelle que soit la fagon dont sont collectees les donnees, celles-ci sont saisies dans la 
base dans un etat dit « a valider ». Tant que les donnees ne sont pas validees par les 
salaries de I'association, des modifications peuvent etre apportees aux donnees. 

La validation des donnees se fait uniquement par les salaries de I'association qui ont le 
droit de modifier la base de DataBirds. lis doivent verifier que les donnees saisies sont 
coherentes. Plus precisement, ils doivent valider les noms des observateurs (les noms 
doivent correspondre a des noms d'adherents) et I'espece (celle-ci doit correspondre a 
une espece connue sur le territoire). 

Apres validation, une saisie se trouve soit dans I'etat dit « valide », soit dans I'etat dit 
« non valide ». Les saisies dans I'etat « non valide » sont automatiquement purgees de la 
base une fois par semaine. 

Grace aux donnees saisies et validees, I'association souhaite pouvoir etablir differents 
types de cartes de presence des differentes especes : 

• Cartes geographiques par espece presentant un cumul historique des populations. Ce 
traitement peut etre demande par un adherent. 

• Cartes des observations realisees par chaque observateur. Ce traitement peut etre 
demande par un salarie uniquement. 

Ces cartes de presence des oiseaux sont generees par DataB irds et accessibles soit par le 
Web, soit par demande via un courrier electronique ou postal. 
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83. Effectuez la premiere etape de la methode. 

L'objectif de cette etape est de produirelediagrammedecas d' utilisation du niveau 
besoin. Nous i dentifions deux acteurs, les adherents et les salaries. II n'y a pas de 
relation d' heritage entreces acteurs, car rien n'obligeun salariea etreaussi adherent 
del'association. 

Les cas d'utilisation associes a I 'adherent sont la realisation d'une observation (la 
saisie des informations relatives a I 'observation) et I'obtention de la carte geogra- 
phique relative a une espece. Les cas d'utilisation associes au salaries sont la valida- 
tion d'une observation et I'obtention de la carte des observations d'un adherent. 
L'application doit aussi permettre la suppression des observations qui n'ont pas ete 
validees, mais cette fonctionnal ite n'etant reliee a aucun acteur, el I e doit etre effec- 
tive automatiquement une fois par semaine. Etant donne que les cas d'utilisation 
represented I es foncti onnal i tes offertes par I ' appl i cati on a son envi ronnement, cette 
fonctionnal ite de suppression des observations ne sera pas representee au niveau 
besoin. 

La figure 46 represents le diagramme de cas d'utilisation du niveau besoin de 
l'application DataBirds. 




84. Effectuez la deuxieme etape de la methode (niveau besoin - comportement). 



L'objectif de cette etape est de produire un diagramme de sequence nomi nal par cas 
d'utilisation ainsi qu'un diagramme de sequence pour chaque erreur possible. 



Corriges des TD 



Chapitre 11 

Pour lefonctionnement nominal du cas d' utilisation Reaiiser une observation, nous 
considerons que I'adherent Jean realise I 'observation qu'il a faite sur trois merles a 
Paris, le l er juillet 2006, a 12 heures. Le message r§aiiserObservation() est envoye 
a I'application DataBirds, qui cree I'objet obsi de type observation. 

L'interaction illustree a la figure 47 represente cette execution. 



0 



db:DataBirds 



I ean:Abherent 



realiserObservation ("merle",3,"paris" , "01/07/06" , "12h00" , "J ean'" 




Figure 47 

I nteraction represents nt la realisation d'une observation 

Pour un fonctionnement soulevant une erreur du cas d'utilisation « Reaiiser une 
observation », nous considerons le cas ou I'adherent oublie de donner le nom de 
I'observateur. Dans ce cas, I'application DataBirds doit signaler une erreur. Ce 
f oncti onnement est represente par I ' i nteracti on i 1 1 ustree a I a figure 48. 



Figure 48 

I nteraction 
representant 
la realisation 
d'une observation 
levant une erreur 



0 



db:DataBird5 



I ean:Ahherent 



realiserObservation ("dauphin", 3, "paris" , "01/07/06" , "12h00" 



erreur: nom de I'observateur non saisi 
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Nous considerons maintenant le fonctionnement nominal du cas d'utilisation 
« Val ider une observation ». Un salarie demande a I ' appl ication de valider une 
observation, et cette derniere lui repond que tout est correct. L'interaction illustree 
a la figure 49 represente ce fonctionnement. 



Figure 49 

Interaction 
representant 
la validation 
d'une observation 



0 



db:DataBirds 



Pierre:fealarie 





validerObservation (obsl) 


1 
1 


K 


ok 


i 

1 
1 
1 

J 

1 
1 
1 



Nous n'avons presente ici qu'une petite partie du diagramme de sequence a 
produire. Ce dernier doit conteni r un diagramme pour le fonctionnement nominal de 
chaquecasd'utilisation etun ou plusieursdiagrammes pour chaque fonctionnement 
errone. 

Pour assurer la coherence entre les parties fonctionnelle, comportementaleet struc- 
ture! I e, nous rappelons que les interactions doivent faireapparattre les acteurs iden- 
tifies a I'etape 1 et les classes qui seront uti I i sees a I'etape 3. 

85. Effectuez la troisieme etape de la methode. 

L'objectif de cette etape est de produire un diagramme de classes representant les 
donnees specifiers dans la description de I ' appl i cati on. Les interactions que nous 
avons donnees en solutions de la question precedente font apparattre les classes 

DataBirds et Observation. 

Nous introduisons la classe Adherent, car I ' appl i cati on doit pouvoir verifier que les 
observations sont faites par des adherents. Les operations associees aux cas d'utili- 
sation sont des operations de la classe DataBirds. Les attributs de la classe observa- 
tion permettent de stacker toutes les caracteristiques d'une observation. 

Nous avons introduit deux booleens. Lebooleen avaiider esta vrai lorsque I'obser- 
vation n'a pas encore ete val idee par un salarie. Lorsque cebooleen esta vrai, il faut 
regarder lebooleen valide pour savoir si I 'observation est effectivement val idee. Les 
classes DataBirds et observation sont associees, car plusieurs observations sont 
gerees par I ' appl i cati on. De la memefagon, nous representons le fait que plusieurs 
adherents peuvent etre identifies. 

La figure 50 represente le diagramme de classes obtenu. 
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Observation 



-espece:string 

-nombrelndividus:integer 

-lieu:string 

-daterstring 

-heure:string 

-aValidenboolean 

-validee:boolean 

-observateurs string [*] 



observation 



DataBirds 



+realiserObservation() 
+validerObservation() 
+obtenirCarteGeographique() 
+obtenirCarteObservation() 



Adherent 


adherent 


-nom:string 
-prenomstring 


* 





Figure 50 

Classes de I ' appl ication DataBirdsau niveau besoin 



86. Effectuez la quatrieme etape de la methode. 

L'objectif de cette etape est de produire la liste des composants du systeme et un 
diagrammedecas d'utilisation par composant. 

Nous decomposons notre systeme en deux composants : le gestionnaire des obser- 
vations et le gestionnaire des cartes. 

Le gestionnaire des observations s'occupe de la creation, de la validation et de la 
suppression des observations. Etant donne que nous sommes au niveau conceptuel, 
nous representons cette fois la suppression des observations. Ce composant est relie 
aux acteurs Adherent et saiarie, qui sont concerned par la creation et la validation 
des observations. II est aussi relie a la base des adherents, qui est un composant 
externea I'application. 

Dans le descriptif de I'application, aucune information n'est donnee sur la gestion 
des adherents. Nous savons juste qu'il est necessaire d' avoir acces a une base des 
adherents. II s'agitdonc d'un composant externea I'application DataBirds. 

La figure 51 represente le diagramme de cas d'utilisation du composant de gestion 
des observations. 
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Gestion des observations 




Salarie 



Figure 51 

Diagramme de cas d ' uti I i sati on du composant Gestion des observations 

Le gestionnaire de cartes s'occupe de la construction des differentes cartes que 
peuvent demander les acteurs. II contient deux cas d' utilisation, la construction des 
cartes geographiques et celle des cartes d' observation. Ce composant est relie aux 
acteurs Adherent et Salarie, car ils ont chacun acces a un des cas d'utilisation qu'il 
contient. II estaussi relie a une base dedonnees des observations, caril enabesoin 
pour produire les cartes demandees. 

Cette base de donnees est en fait produite par le composant de gestion des observa- 
tions, mais comme il n'est pas possible d'etablir des liens entre composants, nous 
devons le representer par un acteur. Notons que I'acteur BDObservation n'est pas une 
personne physique, ce qui ne pose aucun probleme puisque nous sommes au niveau 
conceptuel. 

La figure 52 represente le diagramme de cas d'utilisation du composant de gestion 
des cartes. 

II nefaut pas oublier de preciser les relations de resolution entre les cas d'utilisation du 
niveau d'analyse et ceux des composants. Dans notre cas, cette tache est assez simple : 

• Le cas d'utilisation « Realiser une observation » est resolu par I e cas d'utilisation 
« Creation Observation ». 

• Le cas d'utilisation « Obtenir une carte geographique » est resolu par le cas 
d'utilisation « Construire Carte geographique ». 

• Le cas d'utilisation « Valider une observation » est resolu par le cas d'utilisation 
« Valider Observation ». 

• Le cas d'utilisation « Obtenir une carte des observations » est resolu par le cas 
d'utilisation « Construire Carte observations ». 

87. Effectuez la cinquieme etape de la methode. 

L'objectif de cette etape est de produire un diagramme de sequence nomi nal par cas 
d'utilisation, ainsi qu'un diagramme de sequence pour chaque erreur possible. 
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Salarie 



Figure 52 

Diagramme de cas d' utilisation du composant de gestion des cartes 



N ous reprenons I ecasd' utilisation qui consiste a validerune observation. Cettefois, 
comme nous sommes au niveau conceptuel, nous devons faire apparaitre les diffe- 
rentes etapes de la validation : la verification que les observateurs sont bien des 
adherents (ce qui necessite un acces a la base de donnees des adherents) et la verifi- 
cation que I'espece observee est bien repertories dans le territoire concerne. 

La figure 53 represente I' interaction associee a ce cas d'utilisation. 



Pierre:Ealarie 




Figure 53 

I nteraction au niveau conceptuel representant la validation d'une observation 



Nous n'avons presente ici qu'une petite parti e du diagramme de sequence a 
produire. Ce dernier doit en effet contenir un diagramme pour le fonctionnement 
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nominal de chaque cas d' utilisation et un ou plusieurs diagrammes pour chaque 
fonctionnement errone. 

Pour assurer la coherence entre les parties fonctionnelle, comportementaleet struc- 
ture! I e, nous rappelons que les interactions doivent faireapparaitre les acteurs iden- 
tifies a I ' etape 4 et I es c I asses uti I i sees a I ' etape 6. 

88. Effectuez la sixieme etape de la methode. 

L'objectif de cette etape est de produire les classes des composants. Toutes les 
cl asses d' un meme composant sont regroupees dans un meme package. 1 1 est i mpor- 
tant de preciser aussi les relations de dependance entre les composants. 

Lecomposant« Gestion des Observation » est represente par I e package gestionob- 
servation. II contient les classes Espece et observation, qui represented respective- 
ment les especes visibles sur leterritoireet les observations faites par les adherents. 
Le composant contient aussi la classe BaseDeDonnees, qui contient (relation de 
composition) I'ensemble des especes et I'ensemble des observations. Cette classe 
possede aussi les operations qui seront uti I i sees par I'environnement du composant 

(ajouterObservation( ), val iderObservation( ), supprimerObservationsNonVal idees( )). 

Le composant « Gestion des cartes » est represente par le package gestionCartes. 
Nous avons fait le choix de creer la classe carte, qui est une classe abstraite. Notre 
intention est de stacker dans une memoire cache n'importe quelle carte (geogra- 

phiqueOU Observation) deja COnstruite. Les Classes CarteGeographique et CarteObser- 

vation heritent done de cette classe abstraite. Celles-ci sontassocieesaux classes du 
composant « Gestion des Observation » dont el les ont besoin. La classe Gestionnai- 
reCarte contient I'ensemble des cartes deja creees et possede les operations qui 
seront uti I i sees par I'environnement du composant (constmireCarteGeographiqueO, 

construi reCarteObservation( ), rechercheCarte( )). 

Soulignons que cette specification de la structure des composants n'est pas 
complete. Nous la jugeons cependant suffisante pour notre propos. 

89. Effectuez la septieme etape de la methode. 

L'objectif de cette etape est de produire les classes des composants en integrant les 
classes de la plate-forme d'execution. A partir de la specification des composants 
faite a la question precedente, il suffit de remplacer les associations de multi pi i cite 
* par des liens vers la classe ArrayList. Ces modifications sont representees a la 
figure 55. 

Les liens d'abstraction entre les niveaux conceptuel et physique sont relativement 
triviaux car ils apparaissent entre les packages de meme nom. Pour ce qui est des 
liens d'abstraction pour les associations a mul ti pi i cite * , il faut refaire ce qui a ete 
presente au TD8. 

90. Effectuez la huitieme etape de la methode sur une seule classe. 

L'objectif de cette etape est de produire les cas de test abstraits. 

A titre d'exemple, nous pouvons specifier les cas de test abstrait de la classe BaseDe- 
Donnees et ecrire les tests abstraits concernant la validation d'une observation. Une 
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gestionObservation 



BaseDeDonnees 



■territoireistring 



-tajouterObservationO 
-tvaliderObservation() 
-tsupprimerObservationsNonValideesQ 



espece 



Espece 



^>-nom:string <J 



esp?ce 



observation 



Observation 



id :integer 
espece :string 
nblndividus :integer 
date:string 
heure:string 
observateurs:string[* 
aValidenboolean 
validee:boolean 



observation 



gestionCartes 



GestionnaireCarte 


carteEnCache 






Carte 


+rechercheCarte() 

-tconstruireCarteGeographiqua!) 

4construireCarteObservation() 


♦ > 

1 * 


-id:integer 



CarteGeo 


graphique 









CarteObservation 



adherentstring 



Figure 54 

Classes des composants de gestion des observations et de gestion des cartes 
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Array Li st 



"< 



7N~ 



gestionObservation 



BaseDeDonnees 



■territoire:5tring 



46jouterObservation{) 
-fvaliderObservationf) 
45upprimerObservationsNonValidees() 



Espece 

-nom:string 



Observation 

-id:integer 
-espece: string 
-nblndividu5:integer 
-date:string 
-heure:string 
-observateurs:string[*] 
-aValider: boolean 
-validee:boolean 



gestionCartes 



GestionnaireCarte 



+rechercheCarte(} 

-r-construireCarteGeographiqueO 

+cori5truireCarteOb5ervation(} 



Carte 

-id:integer 



I 



CarteGeographique 



CarteObservation 






-adherentstring 









Figure 55 

Classes des composants au niveau physique 
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faute eventuelle serai t de valider une observation portant sur une espece n'apparte- 
nant pas au territoire. 

U n cas de test visant a reveler une telle faute est specific 1 a la figure 56. 



testeur: 




creation 






















db:BaseDeDonnees 








► 


ajoute ("Observation 


"dauphin",3,"paris" , "01/07/06" 


"12h00" 


i 

, "jean") 


|< 




obsl 

validerObservation (obsl) 




h 










» 


l< 











Resultatattendu : I'observation ne doit pas etre validee 



Figure 56 

D iagramme de cas de test de la classe BaseDeDonnees 

91. Effectuez la neuvieme etape de la methode. 

L'objectif de cette etape est de produire le diagramme de cas d' utilisation represen- 
tant les fonctionnalites offertes par les composants mais au niveau physique. 

Cependant, cette etape n'est necessaire que si certaines fonctionnalites sont real i - 
sees par la plate-forme d'execution. Cela permet en ce cas de faire apparattre les 
fonctionnalites directement offertes par la plate-forme et celles qu'il faudra deve- 
lopper. 

Etant donne que, dans notre cas, aucune fonctionnal ite n'est directement offerte par 
la plate-forme, cette etape n'est pas necessaire. 



1 
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package repertoire; 

public class MyAssistant ( 

public static void main(String[] args) { 
UIRepertoire ihm = new UIRepertoi ret ) ; 

} 

} 
/ 

package repertoire; 

import java.awt. event.*; 
import javax. swing.*; 
import javax. swing. event.*; 

public class UIRepertoire extends JFrame { 
Repertoire theRepertoire; 
UIMenuActionLi stener menuListener ; 
JMenuBar menu_barre; 

JMenu repertoi re_menu, fonction_menu, aide_menu; 

JMenuItem repertoi re_menu_ouvri r, 
repertoi re_menu_enregistrer , 
repertoi re_menu_enregi strersous , 
repertoi re_menu_nouveau, 
f oncti on_menu_a jouterPersonne , 
foncti on_menu_rechercherPersonne , 
aide_menu_item; 



JSplitPane splitPane; 
JList repertoi reView; 
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UlPersonne uipersonne; 

public Repertoire getTheRepertoi re( ) { 
return theRepertoire; 

} 

public void setTheRepertoire(Repertoire theRepertoire) { 
this.theRepertoi re = theRepertoire; 
ref reshUIRepertoi re( ) ; 

} 

public UIRepertoi re( ) { 

superC'Mon Repertoire"); 

menuListener = new UIMenuActionListener(this) ; 
WindowListener 1 = new WindowAdapter( ) { 

public void windowClosingtWindowEvent e) { 
System.exit(O) ; 

} 

public void windowClosed(WindowEvent e) { 
System.exit(O) ; 

} 

}; 

addWindowListenerd ) ; 
initO; 



public UIRepertoi re( Repertoi re rep) { 
superC'Mon Repertoire"); 
theRepertoire = rep; 

menuListener = new UIMenuActionListener(this) ; 
WindowListener 1 = new WindowAdapter( ) { 

public void windowClosingtWindowEvent e) { 
System.exit(O) ; 

} 

public void windowClosed(WindowEvent e) { 
System.exit(O) ; 

} 

}; 

addWindowListenerd ) ; 
initO; 

ref reshUIRepertoi re( ) ; 



void initO { 

//Barre de Menu 

menu_barre = new JMenuBarO; 

setJMenuBar(menu_barre) ; 

// Menu FICHIER 

repertoi rejnenu = new JMenuC'Fichier") ; 

menu_bar re. add ( repertoi re_menu) ; 

repertoi re_menu_nouveau = new JMenuItemt "Nouveau" ) ; 
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repertoi re_menu.add( repertoi re_menu_nouveau) ; 

repertoi re_menu_nouveau. addAct ion Li stener (menu Li stener) ; 

repertoi re_menu_ouvri r = new JMenuItem( "Ouvri r" ) ; 

repertoi re_menu. add (repertoi re_menu_ouvri r) ; 

repertoi re_menu_ouvri r.addAct ion Listener (menu Listener) ; 

repertoi re_menu_enregi strer = new JMenuItem( "Enregistrer" ) ; 

repertoi re_menu. add ( repertoi re_menu_enregi strer) ; 

repertoi re_menu_enregi strer .addAct ion Listener (menu Listener) ; 

//fichier_menu_enregistrer.setMnemonic(KeyEvent.VK_S) ; 

repertoire_menu_enregistrersous = new JMenuItemCEnregistrer Sous"); 

repertoi re_menu.add( repertoi re_menu_enregistrersous) ; 

repertoi re_menu_enregi strersous . addAct i on Li stener (menu Li stener ) ; 

// Menu FONCTION 

fonction_menu = new JMenuCOrganisation") ; 
menu_barre.add(fonction_menu) ; 
fonction_menu_ajouterPersonne = 

new JMenuItemt "Ajouter Nouvelle Personne"); 
fonction_menu. add (fonction_menu_aj outer Personne) ; 
fonction_menu_ajouterPersonne.addActionLi stener (menuLi stener) ; 
fonction_menu_rechercher Personne = 

new JMenuItemt "Rechercher Personne(s)") ; 
fonction_menu. add (fonction_menu_rechercher Personne) ; 
fonction_menu_rechercher Personne. addAct ion Li stener(menuLi stener) ; 

// Menu AIDE 

aidejnenu = new JMenuC'Aide"); 
menu_barre.add(aide_menu) ; 
aide_menu_item = new JMenuItemt "A Propos"); 
aide_menu_i tern. addActi on Li stener (menu Li stener) ; 
ai de_menu . add ( ai de_menu_i tern) ; 

//Mettre un SplitPane 

splitPane = new JSpl itPane(JSpl itPane.HORIZONTAL_SPLIT) ; 
getContentPane( ) . add(spl i tPane) ; 
setVisible(true) ; 
pack( ) ; 



public void refreshUIRepertoi re( ) { 
// Mettre la JList a gauche 

repertoireView = new J Li st(theRepertoi re. 1 isterPersonnes( ) ) ; 
repertoi reView. add Li stSelecti on Li stener (new ListSelectionListener( ) { 
public void valueChanged(ListSelectionEvent e) { 
System. out. print! n( "Ok") ; 

Personne p = (Personne) repertoireView. getSel ectedVal ue( ) ; 
ui personne. set Per sonnet p) ; 

} 

}); 

spl i t Pane. set LeftComponentt new JScrol 1 Pane ( repertoi reView) ) ; 
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//Test a droite 

if (theRepertoi re. 1 i sterPersonnest ) . 1 ength !=0) { 

uipersonne = new UIPersonnettheRepertoi re. 1 i sterPersonnest )[0] ) ; 
spl it Pane. set RightComponent(ui personne) ; 



package repertoire; 

import java.awt.GridLayout; 
import java.awt. event.*; 
import javax. swing.*; 



public class UlPersonne extends JPanel 
Personne personne; 
JTextField nomTF, 
prenomTF, 
telMaisonTF, 
telPortTF, 
telBurTF, 
faxTF, 
titreTF, 
socTF, 
addTF, 
mailTF; 

public UIPersonne( ) { 
super( ) ; 
initO; 

} 

public UIPersonne(Personne p) ( 
super( ) ; 
personne = p; 
initO; 



public Personne getPersonne( ) { 
return personne; 

} 

public void setPersonne( Personne personne) ( 
this. personne = personne; 
prenomTF. setText( personne. get Prenomt ) ) ; 
nomTF. setText( personne. getNom( )) ; 
tel BurTF. setText( personne. getTel ephoneBureau( ) ) ; 
tel Ma isonTF.setText( personne. getTelephoneMai son( ) ) ; 
tel PortTF.setText( per sonne. getTel ephonePortabl e( ) ) ; 
faxTF.setText (per sonne. get Fax ( ) ) ; 
titreTF. setText(personne.getTitre( ) ) ; 
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socTF. setText(personne.getSociete( ) ) ; 
//Adresse 

mailTF.setText(personne.getMail ( )) ; 



public void init( ) { 

this.setLayout(new Gridl_ayout(0, 2)); 
addtnew JLabel ( "nom" ) ) ; 
nomTF = new JTextFieldC"); 
add(nomTF) ; 

add(new JLabel ( "prenom" )) ; 
prenomTF = new JTextFieldC'"); 
add(prenomTF) ; 

addtnew JLabel ( "tel ephone maison")); 
telMaisonTF = new JTextFieldC'"); 
add(telMaisonTF) ; 

addtnew JLabel ( "tel ephone portable")); 
telPortTF = new JTextFieldC"'); 
add(telPortTF); 

addtnew JLabel ( "tel ephone bureau")); 

telBurTF = new JTextFieldC'"); 

add(telBurTF); 

addtnew JLabel ( "fax" )) ; 

faxTF = new JTextFieldC"); 

add(faxTF); 

addtnew JLabel ("titre")); 
titreTF = new JTextFieldC'"); 
addttitreTF) ; 

addtnew JLabel ( "societe" )) ; 
socTF = new JTextFieldC"); 
add(socTF) ; 

addtnew JLabel ( "adresse" )) ; 
addTF = new JTextFieldC"); 
add(addTF); 

addtnew JLabel ( "mai 1 ")) ; 
mailTF = new JTextFieldC'"); 
add(mailTF); 

JButton save = new JButtont "Save" ) ; 
save.addActionListenertnew ActionListenert ) { 
public void actionPerforntedtActionEvent e) { 

pe rsonne. set Prenomt prenomTF. getText ( ) ) ; 

personne. setNomtnomTF. getText ( ) ) ; 

pe rsonne. setTel ephoneBureauttel BurTF. getText ( ) ) ; 

pe rsonne. setTel ephoneMai son (tel Mai sonTF. getText ( ) ) ; 

personne. setTel ephonePort able (tel PortTF. getText ( ) ) ; 

personne. set Fax(faxTF. getText ( ) ) ; 

personne. setTitre( titreTF. getText ( ) ) ; 

pe rsonne. setSociete(socTF. getText ( ) ) ; 

//personne. setAdresse( addTF. getText ( ) ) ; 

personne. setMail (mailTF.getText( )) ; 

} 

}); 
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add(save) ; 

JButton cancel = new JButton( "Cancel ") ; 
cancel .addActionl_istener(new ActionListenert ) { 
public void actionPerformedtActionEvent e) { 

prenomTF.setText (per sonne. get Prenomt ) ) ; 

nomTF.setText(personne.getNom( ) ) ; 

tel BurTF. setText( per sonne. getTel ephoneBureau( ) ) ; 

telMaisonTF.setText(personne.getTelephoneMai son( ) ) ; 

tel PortTF.setText(personne. getTel ephonePortable( ) ) ; 

faxTF.setText(personne.getFax( ) ) ; 

titreTF. setText(personne.getTitre( ) ) ; 

socTF.setText(personne.getSociete( ) ) ; 

//Adresse 

mailTF.setText(personne.getMail ( ) ) ; 

} 

}); 

add(cancel ) ; 



package repertoire; 

import java.awt. event.*; 
import javax. swing. JMenuItem; 

public class UIMenuActionListener implements ActionListener { 
UIRepertoire uirep; 

public UIMenuActionListener(UIRepertoire uirep) { 
super( ) ; 

this. uirep = uirep; 

} 

public void actionPerformedtActionEvent ev) { 



JMenuItem test = (JMenuItem) ev.getSource( ) ; 
if (test.getTextt ) == "A Propos") 

System. out. printlnC'Aide") ; 
else if (test.getText( ) == "Rechercher Personne(s)") { 

System. out. printlnC LOAD "); 



else if (test.getText( ) == "Ajouter Nouvelle Personne") { 
System. out. printlnCAjouter Nouvelle Personne "); 
Personne p = new PersonneO; 
ui rep.getTheRepertoi re( ) .ajouterPersonne(p) ; 
ui rep. ref reshUIRepertoi ret ) ; 



else if (test.getText( ) == "Rechercher Personne(s)") { 
System. out. println("LOAD "); 



/ 



/ 



else if (test.getText( ) == "Nouveau") { 
System. out. printlnC'Nouveau ") ; 
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ui rep . setTheRepertoi re ( new Repertoi re( ) ) ; 

} 

else if (test.getTextt) == "Enregistrer Sous") { 
System. out. printlnCLOAD "); 

} 

else if (test.getTextt ) == "Enregistrer") { 
System. out. println("LOAD "); 

} 

else if (test.getTextt) == "Ouvrir") { 
System. out. printlnCLOAD "); 

} 

} 

} 

/ / 
package repertoire; 

public class Adresse ( 
String pays; 
String region; 
String codePostal ; 
String ville; 
String rue; 

public String getCodePostal ( ) { 
return codePostal ; 

} 

public void setCodePostal (String codePostal) { 
this. codePostal = codePostal; 

} 

public String getPaysO { 
return pays; 

} 

public void setPays(String pays) { 
this. pays = pays; 

} 

public String getRegionO { 
return region; 

} 

public void setRegion(String region) { 
this. region = region; 

} 

public String getRueO { 
return rue; 

} 
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public void setRue(String rue) 
this. rue = rue; 



public String getVilleO { 
return ville; 

} 

public void setVilletString ville) { 
this. ville = ville; 

) 



package repertoire; 

public class Personne { 
String nom; 
String prenom; 
String telephoneMaison; 
String telephonePortable; 
String telephoneBureau; 
String fax; 
String titre; 
String societe; 
Adresse adresse; 
String mail ; 

public Adresse getAdresseO ( 
return adresse; 

} 

public void setAdresse(Adresse adresse) { 
this. adresse = adresse; 



public String getFaxO { 
return fax; 

} 

public void setFax(String fax) 
this. fax = fax; 

} 

public String getMailO { 
return mai 1 ; 



public void setMail (String mail) { 
this. mail = mail ; 

) 



Code d'un carnetd'adresses 

Annexe 1 



public String getNomO { 
return nom; 

} 

public void setNom(String nom) { 
this. nom = nom; 

} 

public String getPrenomO { 
return prenom; 

} 

public void setPrenom(String prenom) { 
this. prenom = prenom; 

} 

public String getSocieteO { 
return societe; 

} 

public void setSociete(String societe) { 
this. societe = societe; 

} 

public String getTel ephoneBureau( ) { 
return telephoneBureau; 

} 

public void setTelephoneBureautString telephoneBureau) { 
this. telephoneBureau = telephoneBureau; 

} 

public String getTel ephoneMai son( ) { 
return telephoneMaison; 

} 

public void setTelephoneMaison(String telephoneMaison) { 
this. telephoneMaison = telephoneMaison; 

} 

public String getTel ephonePortabl e( ) { 
return telephonePortable; 

} 

public void setTelephonePortable(String telephonePortable) { 
this. telephonePortable = telephonePortable; 

} 

public String getTitreO { 
return titre; 

} 
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public void setTitretString titre) { 
this.titre = titre; 

} 

public String toStringO { 
return nom+" "+prenom; 



package repertoire; 

import java.util .Iterator; 
import java.util .ArrayList; 



public class Repertoire { 
ArrayList personnes; 

public void ajouterPersonne(Personne p) { 
personnes. add(p) ; 



public void supprimerPersonnet Personne p) { 
personnes . remove(p) ; 

} 

public Personnel rechercherPersonnesParNom(String nom) { 
ArrayList success = new ArrayListO; 

for (Iterator it = personnes . iterator( ) ; it.hasNextO ;) { 
Personne current = (Personne) it.nextO; 

if (current. getNom( ) .compareTo(nom)==0) success. add(current) ; 

} 

Personnel res = new Personne[0]; 

return (Personnel!]) success. toArray(res) ; 

} 

public Personnel] 1 isterPersonnest ) { 
Personnel res = new Personne[0]; 
return (Personnel!]) personnes. toArray(res) ; 



public RepertoireO { 

personnes = new ArrayListO; 

} 

} 
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Exemple de parti el 



Nous proposons ici un partiel donne, le 31 mars 2005, a une promotion de quatre-vingt- 
dix etudiants de L3 de I'll niversite Pierre et Marie Curie. Sa duree eta it de deux heures, 
et tous documents etaient autorises. Chacune des quatre question de cours est notee sur 
1 point et chacun des huit exercices sur 2 points, soit un total de vingt points. 

Cette annexe est parti culierement destinee aux enseignants desireux de transmettre les princi- 
pesdebasedel'approcheUM L pour le developpeur a des etudiants deL 3 (bac +3). 



Questions de cours (4 points) 

1. Definissez les approches Model Driven, Code Driven et Round Trip. 

Voir, au chapitre 5, la section « Approches envisageables ». 

2. Definissez les differents cas permettantd'identifierdes dependances entre deux classes. 

Voir, au chapitre 4, la section « Qu'est-cequ'unedependance? ». 

3. L'heritage multiple entre classes UML est-il possible? Que signifie-t-il pour les objets 
instances ? 

Oui. Les instances appartiennentaux deux ensembles d'objets definis par les classes 
(intersection). Voir, au chapitre 2, la section « Heritage entre classes ». 

4. Est-il possible de genererune application C++ a partird'un modele UML ? 

0 ui , tout comme i I est possi bl e de generer du J ava. L es I i mi tes sont sensi bl ement I es 
memes, c'est-a-dire qu'il faut recopier les lignes de code dans les model es et done 
faire du recopiage de code. 



194 



UML pour les developpeurs 



Exercices (16 points) 



De jeunes etudiants de Paris VI ont developpe une application permettant de faire 
calculer a des robots des itineraires dans des zones geographiques jonchees d'obstacles. 

La figure 1 illustre une zone geographique composee de sept obstacles (represents par 
des disques noirs) avec un robot (represente par un triangle) devant calculer les itine- 
raires permettant d'acceder a la cible (representee par une etoile). 



Figure 1 

Zone geographique 



A 
















• 


• 


• 


















• 










• 














• 


















• 





II a ete demande aux etudiants de commencer la realisation de I'application par I'elabora- 
tion d'un modele UML. 



Le diagramme de la figure 2 represente toutes les classes du modele UML realise par les 
etudiants. 

5. Commentez le diagramme de classes fourni paries etudiants, etexpliquez la signification 
de chacune des classes vis-a-vis de la problematique enoncee dans le sujet. Presentez 
chacun des attributs et chacune des associations. 

L a classe zoneGeographique represente une zone geographique sous forme de gri Ilea 
deux dimensions. L'attri but nbcoionnes correspond au nombre de colonnes de la 
grille, et l'attri but nbLignes au nombre de lignes de la grille. U ne zone geographique 
contient des obstacles a differentes positions dans la grille (association obstacle), 
ainsi que des robots (association habitant). 

La classe Position represente une position dans la grille. L'attri but coionne correspond au 
numero de la coionne de la position, et l'attri but ngne au numero de la ligne de la posi- 
tion. N ous pouvons prendre comme convention que la position 0,0 correspond au coin 
superieur gauche de la grille (cela n'est pas sped fie dans I'enonce du sujet). 

La classe Robot represente un robot. Un robot peut se promener dans la grille afin de 
calculer un itineraire. Les attributs PositionLigne et PositionCoionne representent la posi- 
tion actuelle du robot (il aurait d'ail leurs ete possible de ne pas mettre ces attributs et de 
representer la position du robot par une association vers la classe Position). 
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Figure 2 
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Laclasse itineraire representeun itinerairecalcule par un robot. Un itineraire a une 
position de depart (association depart), une position d'arrivee (association arnvee) 
et un ensemble de positions definissant le chemin (association chemin). 

Apres avoir realise I eur modeleUM L, les etudiants ont utilise la generation decode 
vers Java, lis ont ensuite modifie le code correspondant a la classe Robot afin de 
real iser letraitementdela methode atteindrePosition. 

Voici les modifications qu'ils ont du effectuer sur la classe Robot : 

• Les etudiants Ont ajOUte Un attribut nomme zoneDuRobot, dont le type est ZoneGeo- 
graphique. 

• Les etudiants ont ajoute I 'operation presenceobstacie, dont le code est le suivant : 

public boolean presenceObstacleO'nt x , int y) { 

for (int i=0 ; i < zoneDuRobot. obstacle. size( ) ; i++) { 

Obstacle obs= Obstacl e)zoneDuRobot. obstacle. elementAt(i ) ; 
if ((obs.getColonneO == x) && (pos.getLigne( )== y)) 
return true; 

} 

return false; 

• Les etudiants ont developpe le code de I 'operation atteindrePosition, dont le code 
est le suivant (il n'est pas necessaire de comprendre ce code pour repondre aux 
questions de I'examen) : 

public Itineraire atteindrePosition(Position lieuxH 
Itineraire res = new Itinerai re( ) ; 
int x = positionColonne; 
int y = positionLigne; 
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int i=0; 

while (x!=l ieux.getColonne( ) && y!=l ieux.getLignet ) ) { 
Position pos = new PositionO; 
//A droite 
int droite = x +1 ; 

if (droite < zoneDuRobot.getNbColonnes( ) && !presenceObstacle(droite,y) ) 

{ 

pos. setColonnet droite) ; 
pos.setLigne(y); 

} 

else { // En bas 
int bas = y+lj 

if (bas <zoneDuRobot.getNbl_ignes( ) && ! presenceObstacl e(x , bas)) { 
pos.setColonne(x) ; 
pos.setLigne(bas) ; 

} 

else { //gauche 

int gauche = x-1; 

if (gauche>0 && ! presenceObstacle(gauche , y)) { 
pos. setColonne( gauche) ; 
pos.setLigne(y) ; 

} 

} 

res.setChemin(i++ , pos); 
y = pos .getLignet ) ; 
x = pos.getColonneO; 

} 

return new Itinerai re( ) ; 
} 

6. Faites I'update du modele UML. 

II est necessaire d'ajouter I'association zoneDuRobot et I'operation presenceobs- 
tacieo. Le code de I'operation atteindrePosition doit etre ajoute en note. 

La figure 3 represente la partie modifiee du diagrammede classes. 



Figure 3 
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7. Construisez un diagramme ne presentant que les dependances entre les classes de 
I'application. 

1 1 suffit de suivre les regies etablies au chapitre 4. 



La figure 4 presents les dependances entre les classes. 



Figure 4 
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8. Est-il possible de deplacer I'operation presenceObstacie dans une autre classe que la 
classe Robot! Est-ce judicieux ? 

Oui, car la classe responsable de cette operation est la classe ZoneGeographique. C'est 
el I e qui contienttoutes les informations pour pouvoir realiser letraitement. 

C'est judicieux, car il y a fort a pari er que d'autres classes que cell edu robot auront 
besoin de savoir si une position est occupee par un obstacle ou non. 



9. L'association entre les classes ZoneGeographique et Robot (dont le nom du crochet de 
I'association est habitant) est-elle necessaire pour I'application? Si oui, pourquoi ? Si 
non, peut-on la supprimer? 

Non. Dans cette application, la zone geographiquen'a jamais besoin de savoir quels 
sont les robots presents (habitant). Nous pouvons done la supprimer ou la rendre 
non navigable. 

10. Apres avoir execute plusieurs fois I'application, il apparait que le code de I'operation 
atteindrePosition n'est pas correct. II sera it meme interessant de pouvoir changer facile- 
mentce code afin de tester plusieurs strategies de calcul d'itineraire. Pour atteindre cet 
objectif, I'enseignant responsable du projet propose aux etudiants d'appliquer le patron 
de conception Strategie. Appliquez ce patron surla classe Robot et I'operation atteindre- 
Position en definissant les strategies VersLaDroite, VersLaGauche et Aleatoire. Expliquez 
I'interetde ce patron. 

Le robot est I'uti lisateur, et I'algori thme est I'operation atteindrePositiono. Nous 
ajoutons done dans la classe Robot I'operation caicuieritiniraireo, qui utilise 
I' algorithms. L'interface ^gorft/ime du patron est representee par I'i interface caicu- 
utineraire. Les differentes strategies qui realisent cette interface sont representees 

par les Classes VersLaDroite, VersLaGauche et Aleatoi re. 



La figure 5 represents I'application dece patron. 
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Figure 5 
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11. Positionnez les classes relatives a la representation geographique dans un package etles 
classes relatives au calcul de I'itineraire dans un autre package. 

NOUS plagons dans le package representationGeographique les Classes ZoneGeogra- 

phique et Position, qui sont les seules a representor effectivement une zone geogra- 
phique. Dans le package calculltineraire, nous placons toutes les autres classes. 

La figure 6 represents ces deux packages. 
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Figure 6 

Decoupe en package de I' appl ication 

12. Definissez un ensemble d'algorithmes, et encapsulez-les dans des classes afin de les 
rendre interchangeables. 

II existe souvent plusieurs algorithmes qui real isent plus ou moins un meme traite- 
ment (les differents algorithmes de tri, par exemple). Les utilisateurs de ces algo- 
rithmes doivent inclure tous les algorithmes s'ils veulent pouvoir changer d'algo- 
rithme en cours d'execution. lis deviennent alors tres gros et diffici lement 
mai ntenabl es. D e pi us, certai ns al gori thmes ne seront pas forcement uti I i ses. II n' est 
alors pas interessant d'inclure le code des ces algorithmes. Pour finir, inclure tous 
les algorithmes dans les applications qui les utilisentfaitqu'il est difficile d'ajouter 
de nouveaux algorithmes. 
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La solution consistea definir une interface definissant la signature del 'execution de 
I'algorithme puis a definir une classe concrete par algorithme different, comme 
il lustre a la figure 7. 
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Patron de conception Strategie 
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de I'Universite Paris 6) a I'OMG. II est egalement auteur de MDA en action, paru chez le meme editeur. 

Isabelle Mounier 

Maitre de conferences a I'Universite Pierre et Marie Curie, Isabelle Mounier enseigne principalement les tech- 
niques de developpement d'applications en licence d'informatique. Ses activites de recherche ont d'abord porte 
sur la verification de proprietes temporelles de systemes informatiques modelises par des reseaux de Petri et 
elle s'interesse aujourd'hui aux aspects formels des langages de modelisation tels qu'UML. 



Un cours d'initiation a UML concu pour les developpeurs et les etudiants en informatique 

La plupart des livres sur UML s'adressent avant tout aux concepteurs et architectes logiciels, selon une demarche « tout-modele » 
dans laquelle la production de code est traitee comme une activite subalterne. Cette approche suscite evidemment des reticences 
chez les developpeurs et deconcerte les etudiants, dont la formation reste axee principalement sur la programmation et qui mesu- 
rent mal les enjeux du formalisme UML. 

UML 2 pour les developpeurs prend le contre-pied de ces approches classiques. L'ouvrage montre comment articuler harmonieu- 
sement modelisation et programmation, en insistant sur les gains de productivite que permettent ces allers-retours entre les 
modeles UML et le code. 



Chaque notion UML importante est introduite par un exemple et chaque chapitre se clot par une serie d'exercices corriges (90 
au total), qui permettront au lecteur de tester ses connaissances. 

Pour illustrer concretement les relations entre code et modeles, les auteurs font le choix du langage Java, les principes presen- 
ts etant naturellement transposables d d'autres langages. 

Au sommaire B 

Pourquoi modeliser • Diagrammes de classes • Reverse Engineering • Retroconception et patrons de conception (design patterns) bj> 
• Generation de code • Diagrammes de sequence • Diagrammes de sequence de test • Plates-formes d'execution • Diagrammes En 
de cas d'utilisation • Developpement avec UML • Corriges des exercices. IS 



Sur le site www.editions-eyrolles.com 

• Dialoguez avec les auteurs 

• Telechargez les modeles et le code source des exemples du livre 



